DMARC Explained: Policies, Alignment and a Safe Rollout

Short answer: DMARC is a DNS TXT record at _dmarc.yourdomain.com that tells receiving servers what to do with messages that claim to come from your domain but fail authentication. A message passes DMARC when SPF or DKIM passes and matches the domain in the visible From address. Start with p=none and reports, fix every legitimate sender, then move to p=quarantine and finally p=reject.

What problem DMARC solves

SPF and DKIM each prove something useful, but neither looks at the address a person actually sees in their inbox. SPF checks the hidden envelope sender, and DKIM checks whichever domain signed the message. A criminal can send a message with a valid SPF pass for their own domain and a From address showing your company name, and neither check would object.

DMARC (Domain-based Message Authentication, Reporting and Conformance, described in RFC 7489) closes that gap. It adds three things:

• Alignment: at least one passing check must belong to the same domain as the visible From address.
• Policy: the domain owner states what receivers should do with messages that fail: nothing, quarantine them or reject them.
• Reporting: receivers send the domain owner reports about the mail they saw using the domain, which reveals both forgotten legitimate senders and abuse.

DMARC has moved from “nice to have” to baseline. Gmail and Yahoo require bulk senders to publish a DMARC record, and a domain without one is an easier target for invoice fraud and phishing that uses your name.

Reading a DMARC record tag by tag

A typical starting record looks like this:

v=DMARC1; p=none; rua=mailto:[email protected]; adkim=r; aspf=r

• v=DMARC1 is the version and must come first.
• p= is the policy for the domain: none, quarantine or reject.
• sp= is an optional separate policy for subdomains. If it is missing, subdomains inherit p=.
• rua= is where aggregate reports go. Without it you fly blind.
• ruf= requests failure (forensic) reports. Few large providers send them, and they can contain personal data, so many domains skip this tag.
• adkim= and aspf= set alignment mode for DKIM and SPF: r for relaxed (the default) or s for strict.
• pct= applies the policy to a percentage of failing mail, which some administrators use to phase in enforcement.
• fo= controls when failure reports are generated.

The record is published as TXT at the host name _dmarc. A domain can have only one DMARC record; two records mean neither is used.

How alignment works

Alignment is the heart of DMARC and the source of most confusion. A message passes DMARC if either of these is true:

1. SPF passes, and the envelope sender domain matches the From domain.
2. DKIM passes, and the signing domain (d=) matches the From domain.

In relaxed mode, “matches” means the same organisational domain, so news.yourdomain.com aligns with yourdomain.com. In strict mode, the names must be identical. Relaxed is right for almost everyone.

The practical consequence: many third-party tools pass SPF and DKIM with their domain. The mail is authenticated, but not aligned, so it fails DMARC. Before you enforce, each of those tools needs custom domain authentication, usually a DKIM key for your domain and sometimes a custom bounce domain for SPF.

The three policies compared

Receivers treat the policy as a strong request rather than an absolute command. They may still apply their own judgement, for example for forwarded mail. But large providers do follow published policies closely, which is exactly why a careless jump to p=reject can bounce your own invoices.

A safe DMARC rollout plan

1. Make sure SPF and DKIM are in place for your main mailbox provider first. DMARC builds on them.
2. Publish p=none with a rua address. Use a dedicated mailbox or a report-processing service, because reports arrive as compressed XML files, often daily from each large provider.
3. Collect two to four weeks of reports. This covers monthly processes such as invoicing and payroll notifications, which are easy to forget.
4. Identify every legitimate source. For each IP range or service in the reports, decide whether it is yours. If it is, configure aligned DKIM (preferred) or aligned SPF.
5. Move to p=quarantine. If you want a gentler step, use pct= with a lower value first and increase it.
6. Watch reports and complaints for a few more weeks. Look for any legitimate stream that now fails.
7. Move to p=reject. Keep receiving reports afterwards; new tools get added over time, and each needs authentication before it starts sending.

Many small businesses stop at p=none and never return. That satisfies the bulk sender rule of “have a DMARC record”, but it gives no protection against spoofing. The value of DMARC comes from enforcement.

Mistakes that make DMARC fail or do nothing

• No rua tag. A policy without reports cannot be safely tightened.
• Publishing at the wrong name, for example at the root domain instead of _dmarc, or at _dmarc._dmarc because the DNS panel appended the prefix twice.
• Two DMARC records, often one added by a hosting wizard and another by hand.
• Jumping straight to p=reject without checking the website mailer, CRM or accounting system, which then bounces customer mail.
• Reports sent to an external domain without authorisation. If rua points to another domain, that domain must publish a record allowing it, or receivers will not send the reports. Report-processing services handle this for you.
• Ignoring subdomains. Attackers can use billing.yourdomain.com if subdomains are not covered. The default inheritance usually protects them, but an explicit sp= makes the intention clear.

Forwarding, mailing lists and other edge cases

Some legitimate mail fails DMARC through no fault of the sender. Knowing these cases helps you read reports calmly instead of panicking at every failure line.

• Forwarding. When a recipient forwards mail automatically, for example from an old university address to a personal mailbox, the forwarding server is not in your SPF record. SPF fails, but an intact DKIM signature still passes and aligns. This is the main reason to sign every stream with DKIM for your own domain rather than relying on SPF alone.
• Mailing lists. Discussion lists often add a footer or change the subject line, which breaks the DKIM signature. Many list servers now rewrite the From address to the list’s own domain when the original domain has a strict policy, precisely to avoid rejections.
• Security gateways. Some inbound filters rewrite links or add warning banners before passing mail on. If that happens inside the recipient’s organisation after DMARC is evaluated, it is harmless; if it happens on your outbound path, it can break your own signatures.
• ARC. The Authenticated Received Chain standard lets intermediaries such as list servers record the authentication results they saw before they modified a message. Large receivers can take that into account, which softens the forwarding problem without any action from you.

In reports, these cases usually appear as a small number of failures from servers you do not recognise, spread across many different sources. A large, steady volume from one unknown source is more likely to be a forgotten tool or abuse, and deserves a closer look before you tighten the policy.

What DMARC does not do

DMARC protects your exact domain. It does not stop lookalike domains such as yourdomain-invoices.com or display-name tricks where the name says your company but the address is a free mailbox. It also does not improve deliverability on its own: a domain with poor list practices and a p=reject policy can still land in spam. Think of DMARC as a lock on your name, and deliverability as the reputation you build by sending mail people want.

Site AI Audit checks whether a DMARC record exists, which policy it sets and whether reporting is configured, next to the SPF, DKIM and MX checks. A missing record is reported as a warning with the exact record to add, as on our free website check. On paid plans the checks repeat, so a DMARC record lost during a DNS migration triggers an alert instead of weeks of silent spoofing.

Related reading

• SPF Record Explained: What It Does and How to Set It Up
• What Is DKIM and How to Set It Up for Your Domain

The bottom line

DMARC connects SPF and DKIM to the address people actually see, tells receivers how to treat failures and reports who sends mail in your name. Publish it with p=none and a report address, use the reports to align every legitimate sender, then move through quarantine to reject. Stopping at none is better than nothing, but only enforcement protects your domain.

FAQ

Is a DMARC record required?

It is not a law, but Gmail and Yahoo require bulk senders to publish one, and other providers treat it as a strong trust signal. For any business domain it is a basic part of e-mail setup.

How long should I stay at p=none?

Long enough to see every legitimate sender in the reports, which is usually two to four weeks. If your reports still show unknown or unaligned legitimate sources, stay until they are fixed.

Will p=reject hurt my deliverability?

Not if every legitimate sender is aligned. It only affects mail that fails DMARC. The risk comes from forgotten services, which is why the reports phase matters.

Why do I receive DMARC reports from providers I never send to?

Reports come from any receiver that saw mail using your domain, including forwarded mail and spoofing attempts. Unknown sources in reports are often exactly the abuse DMARC is designed to reveal.

Do parked domains need DMARC?

Yes. Domains that never send mail should publish p=reject together with an SPF record of v=spf1 -all. This stops criminals from using unused domains that look trustworthy.