Key takeaways

  • DMARC (RFC 7489) lets a domain owner publish a policy of none, quarantine or reject for mail that fails authentication and does not align with the visible From domain.
  • Start at p=none with a reporting address. It changes nothing for delivery, and the aggregate reports show every system that sends mail as your domain.
  • Most rollouts stall on third-party senders: billing platforms, marketing tools, ticketing systems and CRM. Each one needs its own aligned DKIM signature or an SPF-aligned return path.
  • Move to quarantine, then reject, in steps. The pct tag in RFC 7489 can apply a policy to only part of your mail while you watch for damage.
  • Gmail and Outlook.com now require SPF, DKIM and DMARC from bulk senders, so a published record is no longer optional for companies that send at volume.
  • BIMI, which shows a verified logo in some inboxes, is optional and only works after DMARC is at enforcement.

Why DMARC, and why a plan

SPF and DKIM each check one thing about a message. Neither checks the address a person actually sees in the From line. DMARC closes that gap. It asks the receiving server to confirm that SPF or DKIM passed and that the domain they authenticated lines up with the From domain. It then lets you say what should happen to mail that fails: nothing, quarantine it, or reject it. The protocol is defined in RFC 7489.

The risk is on the other side of the coin. A reject policy applied before you know all your senders will bounce real mail. That is why DMARC projects have a reputation for being slow. They do not have to be, if you follow a fixed order and keep each step small. Our article on SPF, DKIM, DMARC and resilient Exchange explains the three records. This one covers the rollout.

Step 1: Inventory and publish p=none

Before you publish anything, list the systems you know send mail as your domain: your mail platform, the website contact form, the accounting system, the newsletter tool, the help desk. Expect to miss some. The reports will find them.

Then publish a DMARC record at the _dmarc name of your domain with p=none and a reporting address in the rua tag. Use a mailbox or a reporting service you control. Aggregate reports are XML files that large receivers send, usually daily, listing which IP addresses sent mail claiming your domain and whether SPF and DKIM passed and aligned. They contain no message content. At p=none, delivery does not change.

Step 2: Read the reports and fix your own mail

Raw XML is hard to read, so most teams use a parsing tool or a managed service. Group results by sending source and sort by volume. For each source ask three questions. Is it ours? Does it pass SPF or DKIM? Is the passing domain the same as, or a subdomain of, the From domain, which is what alignment means under RFC 7489 in relaxed mode?

  • Legitimate and aligned: leave it alone.
  • Legitimate but not aligned: fix it. Usually that means turning on custom DKIM signing for your domain in that service.
  • Unknown: investigate. It is either a forgotten system or someone spoofing you. Both are worth knowing about.
  • Clearly abusive: nothing to fix. This is the mail that enforcement will block.

Also check forwarding. Mail forwarded by a mailing list or an alias can break SPF. DKIM usually survives, which is one reason to sign everything. RFC 7960 documents the interoperability problems between DMARC and mailing lists.

Step 3: Third-party senders

This is where plans stall. Every outside service that sends as you needs one of two things. Either it signs with a DKIM key published in your DNS (the cleanest option), or it uses a return-path domain you control so that SPF aligns. Some vendors do neither unless you ask. A few cannot do it at all.

  • Prefer a dedicated subdomain for each bulk or marketing sender, such as a mail or news name under your domain. It isolates reputation and lets you keep the main domain strict.
  • Keep an owner and a renewal date for each sender. DKIM keys and vendor accounts outlive the person who set them up.
  • Mind the SPF limit of ten DNS lookups in RFC 7208. Piling vendors into one record is the usual way to break it.
  • Remove senders you no longer use. A forgotten account that can still send as you is an attack path.

Step 4: Quarantine, then reject

When the reports show your legitimate mail passing for several weeks, including month-end and any seasonal sending, move to p=quarantine. Use the pct tag to start with a slice, for example a quarter of failing mail, then raise it. Watch for complaints of missing mail and for new failing sources in the reports.

When quarantine has been quiet at 100 percent, move to p=reject in the same way. Reject is the goal for any domain that people could be tricked by, since it is what stops an outsider from sending a convincing message as you. Set the sp tag deliberately: it controls subdomains, and a parked domain that never sends mail should publish a reject policy too.

Typical timelines run from a few weeks for a simple domain to a few months for a company with many systems. Do not rush the quarantine stage.

Why the big mailbox providers care

Google's sender guidelines require SPF, DKIM and DMARC for senders of more than 5,000 messages a day to Gmail accounts, and say the DMARC policy can be none. Microsoft announced similar requirements for domains sending more than 5,000 messages a day to Outlook.com, with non-compliant mail going to Junk and eventually possibly rejection. Check each provider's current page, because details change. The point for a smaller company is that a published, working DMARC record is now ordinary hygiene, and an insurer or a client's vendor questionnaire will ask for it.

Optional: BIMI

Brand Indicators for Message Identification (BIMI) lets a sender publish a logo that some mailbox providers show beside authenticated mail. It is described by the BIMI Group and in an IETF draft. It requires DMARC at enforcement, a properly formatted logo, and often a verified mark certificate, which carries a cost and a trademark requirement. It does not stop any attack. Treat it as a marketing benefit of finishing DMARC, never a reason to start.

Keep it alive

  • Keep reading the reports monthly. New tools get added by people who do not know DMARC exists.
  • Add a DNS change check to your new-vendor process.
  • Alert on a drop in aligned mail volume, which is how a broken DKIM key shows itself.
  • Review the policy when you buy a company, launch a product or move mail platforms.

If you want the rollout run for you, with report parsing, vendor fixes and the move to reject, ask about our Email Security and Archiving service. This article is general information and not a guarantee of delivery or security outcomes.

Sources

This article is general information, not legal or technical advice for your environment. Test DNS and mail changes with your own administrator before enforcing a policy. Last reviewed .

Keep reading

Need help with this?

Filter threats out of mail, keep every message in an immutable archive you can search, and keep email working when the mail platform goes down.

Email Security, Archiving & Continuity