DMARC Record Generator

What is DMARC?

DMARC (Domain-based Message Authentication, Reporting & Conformance) is an email authentication protocol that builds on SPF and DKIM. It tells receiving mail servers what to do when an email fails authentication checks, and provides a reporting mechanism so domain owners can see who is sending email as their domain.

How to create SPF, DKIM and DMARC records

A domain that sends email needs all three records, and DMARC depends on the other two: a message passes DMARC only when SPF or DKIM passes for a domain that aligns with the one in its From address. Before you start, make sure you can edit your domain's DNS, usually at your registrar or hosting provider, and list every service that sends email as your domain: your mailboxes (Microsoft 365 or Google Workspace) plus any marketing, CRM, helpdesk and invoicing tools.

Step 1: SPF

SPF is a single TXT record on the domain itself (the host is usually entered as @) that lists the services allowed to send as you. Our SPF record generator writes the include: for each provider you pick and counts the DNS lookups against SPF's limit of 10. A domain that sends only through Microsoft 365 needs just v=spf1 include:spf.protection.outlook.com ~all.

End the record with ~all on a domain that sends mail and keep -all for parked domains; our guide to SPF hard fail vs soft fail explains why. Add every service on your list, because one that is missing fails SPF. A domain has exactly one SPF record, so edit the one you have rather than publishing a second, which makes SPF return a permerror for every message. If the record needs more than 10 lookups, see how to fix SPF too many DNS lookups.

Step 2: DKIM

DKIM needs two things: your provider signs outgoing mail, which you switch on in its admin console, and you publish the matching public key in DNS under the selector it gives you, at selector._domainkey.example.com. Microsoft 365 uses 2 CNAME records, for the selectors selector1 and selector2. Google Workspace gives you a TXT record under the selector google by default. SendGrid, Mailchimp, Amazon SES and HubSpot each use their own selector and record format, and a key published under the wrong selector cannot be found, so DKIM fails.

Our DKIM generator builds the TXT record from a public key, or makes a key pair in your browser if you sign mail yourself, and the DKIM set-up steps for each email provider go through each platform. Set up DKIM on every service, not just SPF: section 7.4 of RFC 9989 says a domain that publishes p=reject must not rely on SPF alone and must sign its mail with valid DKIM signatures.

Step 3: DMARC

DMARC is one TXT record at _dmarc.example.com. Build it with the generator at the top of this page, starting at monitoring only with a reporting address:

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

In your DNS panel, create a TXT record with the name _dmarc and paste the record as its value; a TTL of 3600 seconds, or your panel's automatic setting, is fine. p=none asks receivers to take no action on mail that fails, so you can publish it while you are still working on SPF and DKIM, and its reports will show you which services still need fixing.

The rua= address is where receivers send aggregate reports. It can be your own mailbox, or a reporting service such as ShieldMarc that parses the XML reports automatically. An address at another domain works only when that domain publishes a record accepting your reports, as the FAQ below explains.

Step 4: Test what you published

1. Check the records. Our SPF, DKIM and DMARC checker validates the DMARC record, analyses SPF and looks for DKIM keys at common selectors and your providers' own. A key under any other selector needs the DKIM checker.
2. Send test emails from your domain to a Gmail and an Outlook mailbox, and look for spf=pass, dkim=pass and dmarc=pass in the Authentication-Results header. Our email header analyser reads it for you.
3. Test each third-party sender. Send a message through every other service on your list, such as a CRM, marketing platform or helpdesk: each needs an aligned SPF or DKIM pass to pass DMARC.
4. Watch the reports. Aggregate reports usually start to arrive within 24 to 48 hours, and our DMARC report viewer opens them. They come from receivers that send them, on days they see your mail, so a quiet day is not proof that nothing was sent.

When the reports show every legitimate sender passing, move towards enforcement as the rollout below describes. Our guide to moving from p=none to p=reject covers each stage in more detail.

DMARC rollout strategy

If the domain sends mail, do not go straight to p=reject. The recommended approach is a three-stage rollout that gives you visibility before you enforce:

1. Start with p=none and an rua= reporting address. This lets you see the senders receivers report for your domain, and no mail is blocked.
2. Read the reports until every legitimate sender passes. They show which services still need SPF or DKIM alignment, and ShieldMarc's readiness check wants 14 days of reports at each step. Use our DMARC Report Viewer to read the XML files, or start a free trial for continuous monitoring.
3. Move to p=quarantine once all legitimate senders are aligned in your reports. Advance when the report data says it is safe, not on a fixed calendar.
4. Advance to p=reject once quarantine reports are clean and no unresolved unauthorised senders remain. This is full enforcement: receivers are asked to refuse mail that fails DMARC.

Why aggregate reports matter

The rua= tag tells receivers where to send XML reports, usually daily, showing the senders they saw using your domain. Without this data, you will not know which legitimate services need SPF or DKIM alignment before you can safely move to enforcement. The reports arrive as compressed XML attachments: use our DMARC Report Viewer to read them, or use ShieldMarc to have them parsed automatically.

Frequently asked questions