Email Infrastructure & Deliverability

DMARC Configuration

DMARC stops others sending mail as your domain and tells you who is trying. We roll it out in stages, so legitimate mail keeps flowing while protection increases.

What DMARC does

Domain-based Message Authentication, Reporting and Conformance (DMARC) is a DNS record at _dmarc.yourdomain.com. It tells receivers two things: what to do with mail claiming to be from your domain that fails SPF and DKIM alignment, and where to send reports about the mail they see.

The policy has three levels: p=none (monitor only), p=quarantine (treat failing mail as suspicious, usually the spam folder) and p=reject (refuse it). Reports come as daily aggregate XML files showing which IPs sent mail as your domain and whether it passed.

DMARC also checks alignment: the domain in your visible From address must match the domain that passed SPF or signed with DKIM. That is what stops someone passing SPF with their own domain while pretending to be you.

Who needs DMARC

  • Any domain that sends bulk email to Gmail or Yahoo users, where DMARC is now expected.
  • Businesses whose customers have received phishing emails appearing to come from them.
  • Organisations with many third-party tools sending as their domain.
  • Anyone planning BIMI, which requires an enforced DMARC policy.
  • Domains that never send mail, which should publish a reject policy to prevent abuse.

The staged rollout

  1. Start at p=none with an aggregate report address (rua), so nothing changes for delivery.
  2. Read the reports for a representative period and identify every source sending as your domain.
  3. Fix legitimate sources that fail or don’t align, by configuring SPF return-paths and custom DKIM.
  4. Move to quarantine, optionally starting with a percentage using the pct tag, and watch for problems.
  5. Move to reject once reports show legitimate mail passing consistently.
  6. Keep monitoring, because new tools get added and old ones change.

Rushing straight to reject is the most common way legitimate mail disappears without anyone noticing, such as invoices from a billing tool that was never aligned.

What’s included

  • A DMARC record with a reporting address and a policy suited to your stage.
  • Collection and readable summaries of aggregate reports.
  • Identification of every legitimate and unknown sender.
  • SPF and DKIM alignment fixes for each legitimate source.
  • Subdomain policy (sp) and alignment mode (adkim, aspf) set deliberately.
  • The staged move to enforcement, with checkpoints agreed with you.
  • Reject policies for parked domains that never send mail.

Standards around DMARC

DMARC builds on SPF and DKIM. Once enforced, it enables BIMI, which can display your logo in supporting inboxes when combined with a correctly formatted logo and, for some providers, a verified mark certificate. Gmail and Yahoo’s bulk-sender requirements include a published DMARC record and alignment, alongside one-click unsubscribe and low complaint rates for opted-in mail.

DMARC is a protection and accountability tool. It helps receivers trust your genuine mail and reject impersonation; it doesn’t make unwanted mail welcome. Permission-based lists and easy unsubscribing still matter.

Reading DMARC reports

Raw aggregate reports are XML files arriving daily from many receivers, which makes them hard to read directly. We collect and summarise them so you can see, per sending source:

  • How much mail was sent as your domain, and from which IPs.
  • Whether SPF and DKIM passed, and whether each aligned.
  • Which sources are legitimate and which are unknown or abusive.
  • How results change after each fix or policy step.

Unknown sources aren’t always attackers. Often they’re a forgotten tool someone in the business signed up for. Reports are how you find them before enforcement blocks their mail.

What affects timeline and cost

  • Number of domains and subdomains.
  • How many third-party services send as your domain.
  • How quickly those services can be reconfigured.
  • The monitoring period needed before each policy step.
  • Whether ongoing report monitoring is included.

Common DMARC mistakes

Publishing p=reject on day one. Publishing p=none with no reporting address, which gives neither protection nor information. Forgetting subdomains. Never reading the reports. Ignoring forwarded mail and mailing lists when interpreting failures.

Related: email authentication, all email infrastructure services, the guide, and contact.

Frequently asked questions

Will DMARC stop our mail being delivered?

Not at p=none. At quarantine or reject, only mail failing alignment is affected, which is why we fix every legitimate source first.

How long before we can move to reject?

It depends on how many sources you have and how quickly they are fixed. We move when reports show consistent passing, not on a fixed date.

What are DMARC aggregate reports?

Daily XML summaries from receivers showing which IPs sent mail using your domain and whether they passed SPF, DKIM and alignment.

Do domains that don’t send email need DMARC?

Yes. A reject policy with an empty SPF record stops criminals using unused domains for phishing.

Should we use forensic (ruf) reports?

Few receivers send them and they can contain personal data, so we treat them as optional. Aggregate reports provide what’s needed for most rollouts.

Talk to us about dmarc configuration

Policy and reporting that stops others spoofing your domain and shows you who tries.

Let's talk

Have something you need built, hosted or fixed?

Tell us what you are trying to do. If we are not the right people for it, we will say so.