How DMARC stops your domain from being spoofed

Email spoofing means sending a message with your domain in the visible From: header without actually controlling your domain's mail systems. SMTP itself places no restriction on what a sender writes in that field - anyone can type billing@yourdomain.com into a From: line. What stops a receiving server from trusting that claim is authentication: SPF, DKIM, and critically, DMARC.

Why spoofing damages more than the one phished recipient

A spoofed message that reaches an inbox and gets reported as phishing or fraud damages your domain's reputation with the mailbox providers who saw it - even though you never sent it. Recipients who get fooled associate the fraud with your brand, not with the actual sender's infrastructure, since your domain is the only identity visible to them.

SPF and DKIM alone don't stop spoofing

SPF authorises which servers can use your domain as the SMTP envelope sender - it says nothing about what a receiving server should do when a message's *visible* From: header doesn't match. DKIM proves a signed message wasn't altered and came from whoever holds the signing key - but a message with no DKIM signature at all (like most spoofed mail) simply has nothing to check.

DMARC closes this gap. It requires that either SPF or DKIM actually be *aligned* with the visible From: domain, and - this is the part SPF and DKIM don't provide on their own - it tells the receiving server explicitly what to do when that alignment fails.

The requirement shift: DMARC is no longer optional at scale

Gmail and Yahoo's bulk-sender requirements both now include having a DMARC record published for domains sending meaningful volume to their users, at minimum at p=none. A domain with no DMARC record at all is, in their rules, already out of compliance for anything beyond small-scale personal sending - independent of whether spoofing is actively happening.

Setting up DMARC to actually stop spoofing

A monitor-only record is a necessary first step, but it alone does not block anything:

_dmarc.yourdomain.com.    TXT    "v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com"

To actually stop spoofed mail from reaching inboxes, the policy has to move past p=none:

_dmarc.yourdomain.com.    TXT    "v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourdomain.com"

p=reject tells receiving servers to refuse delivery outright for any message claiming your domain that fails SPF/DKIM alignment. This is what actually stops spoofed mail - p=none only observes it.

Common setup mistakes that undermine this

• Jumping to `p=reject` immediately. If you have any legitimate sender that isn't yet properly aligned (a forgotten marketing tool, a help desk system, an old script), p=reject will also block *that* mail with no warning - which is why reading p=none reports first matters.
• Forgetting `sp=` for subdomains. By default, a DMARC record applies to the exact domain; subdomain behaviour follows the same policy unless you set sp= differently. An unused subdomain with no mail-sending reason to exist is a common spoofing target precisely because nobody thought to lock it down separately.
• Treating SPF-pass as sufficient and skipping the alignment check. SPF can pass on the envelope sender while the visible From: domain is spoofed - alignment, not SPF alone, is the actual guard.

Tracking reports

Once rua= is set, aggregate reports (sent daily, as XML, from participating receivers) show exactly which sources are sending as your domain and whether they pass or fail alignment. Reading these - manually or through a monitoring tool - is how you confirm it's safe to move from p=none to p=quarantine to p=reject without breaking legitimate mail along the way.

What not to do

• Don't publish DMARC and leave it at p=none indefinitely - that configuration generates visibility but blocks nothing.
• Don't skip straight to p=reject without first reading reports at p=none for several weeks.
• Don't forget to set sp= explicitly if your subdomains don't send mail at all - locking those down separately closes a common spoofing gap.

DMARC policy progression

FAQ

How long should each stage of the DMARC rollout last? There's no fixed rule, but a common pattern is several weeks at p=none reading reports, then a further stretch at p=quarantine once reports show legitimate senders aligning cleanly, before moving to p=reject. Rushing any stage risks blocking mail you didn't know was unaligned.

Can someone still spoof my domain while I'm at p=quarantine? Spoofed mail failing alignment gets routed to spam rather than the inbox at p=quarantine - a meaningful reduction in reach, but not the full stop that p=reject provides, since some recipients do check their spam folder.

What's the percentage tag (pct=) for, and should I use it? pct= lets you apply your policy to only a percentage of failing mail, useful for a gradual rollout of p=quarantine or p=reject rather than an all-at-once switch. Omitting it defaults to 100% - the policy applies to all failing mail from the start.

MailPilot checks SPF, DKIM, and DMARC status, including alignment, for every mailbox domain it monitors, so a gap that would let spoofed mail through - or a policy still sitting at p=none months after it should have moved on - shows up as a specific, trackable check rather than something discovered after a phishing report comes in.