How to set up DMARC

A DMARC record is a single DNS TXT entry that tells the world's mail servers what to do with email that claims to come from your domain but cannot prove it. It is the policy layer that sits on top of SPF and DKIM, and it is the only one of the three that lets you actually stop spoofing rather than merely authenticate your own mail. This guide shows you the exact record to publish, the precise DNS fields to enter, where to add it in every major DNS provider, and the mistakes that trip people up. If you would rather not touch DNS at all, our done-for-you service publishes and manages the record for you and walks it safely to enforcement, but if you are doing it yourself, everything you need is below.

What the record is and why you need it

DMARC, defined in RFC 7489, stands for Domain-based Message Authentication, Reporting and Conformance. When a receiving mail server gets a message that says it is from you@yourdomain.com, it looks up your DMARC record to answer two questions: what should I do with this if it fails authentication, and where do I send a report about it? Without a record, the answer to both is nothing. Anyone can put your domain in the From line and most receivers will deliver it.

The record does not authenticate mail by itself. SPF (RFC 7208) and DKIM (RFC 6376) do that. DMARC ties them together by checking alignment: that the domain which passed SPF or DKIM matches the domain your recipients actually see in the From header. Then it applies your chosen policy and sends you aggregate reports so you can see exactly who is sending mail in your name. That reporting is the whole reason you start gently, at p=none, before tightening anything.

The record to publish

For a brand-new setup, this is the record you start with. It enforces nothing yet. It simply asks every receiver to report back so you can discover your sending sources before you tighten the policy.

v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com

Replace dmarc@yourdomain.com with a mailbox you actually control and can receive mail at. This is not optional decoration: the rua address is where your aggregate reports arrive, and without a working mailbox you are flying blind. You can build a complete, correct record for your situation with our DMARC record generator, which assembles the tags for you and explains each one.

The DNS fields to enter are as follows. The host is always _dmarc, prefixed to your domain.

• Type: TXT
• Host / Name: _dmarc (this becomes _dmarc.yourdomain.com)
• Value: v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com
• TTL: 3600 (one hour) or your provider's default, which is fine

You publish exactly one DMARC record per domain. If two _dmarc TXT records exist, receivers treat the policy as undefined and may ignore both, so never add a second alongside an existing one. Edit the one you have.

What the tags mean

A few tags do almost all the work, and you will adjust them as you move toward enforcement.

• v=DMARC1 is mandatory and must come first. It identifies the record as DMARC.
• p= is your policy: none (monitor only), quarantine (send failing mail to spam), or reject (refuse it outright).
• rua=mailto: is the address for aggregate (daily summary) reports. You can list more than one, comma-separated.
• sp= sets a separate policy for subdomains. Useful for locking down subdomains you never send from.
• rf, ri, fo and ruf are optional and most setups can ignore them. ruf requests forensic (per-failure) reports, which few receivers send and which can carry personal data, so we usually leave it off.

Start at p=none, then move toward enforcement

Publishing the record above changes nothing about how your mail is delivered. That is intentional. At p=none receivers deliver everything as normal and send you reports, and you use those reports to find every system sending mail under your name: your mailbox provider, your CRM, your invoicing tool, your help desk, your marketing platform. A typical organisation is surprised by how many there are.

Once the reports show that every legitimate source is aligned and passing, you tighten the policy to p=quarantine, hold there until you are certain nothing real is landing in spam, then move to p=reject. Only at p=reject is a forged message refused before it reaches the inbox. The full, careful method for doing this without any outage is set out on our guide to reaching enforcement, and the staged records look like this:

v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com

v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc@yourdomain.com

Some guides recommend a pct tag to apply the policy to only a percentage of failing mail during the ramp. It can act as a safety belt on a large, messy estate, but thorough monitoring usually gives you the same certainty without ever junking a legitimate message, and the newer specification work has deprecated it. Treat pct as a transitional tool at most, never a destination. See requirements for what each receiver now expects.

Where to add the record

The record is the same everywhere. Only the interface changes. In every case you are adding a TXT record with host _dmarc and the value above. The single most common mistake across all providers is getting the host field wrong, so read the note on each one carefully.

Cloudflare

Open the Cloudflare dashboard, select your domain, and go to DNS → Records. Click Add record. Set Type to TXT, set Name to _dmarc, and paste the record into the Content field. Leave Proxy status as DNS only (TXT records cannot be proxied) and leave TTL on Auto. Cloudflare automatically appends your domain, so enter _dmarc only, never _dmarc.yourdomain.com. If you type the full name it becomes _dmarc.yourdomain.com.yourdomain.com and will not resolve. Save.

GoDaddy

Sign in and go to your Domain Portfolio, select the domain, and open DNS (or Manage DNS). Click Add (or Add New Record). Choose Type TXT. In the Name (sometimes labelled Host) field enter _dmarc, and in the Value (sometimes TXT Value) field paste the record. Set TTL to 1 hour or leave the default. GoDaddy appends the domain for you, so the Name is _dmarc with no domain suffix. Save.

Namecheap

Sign in, go to Domain List, click Manage next to your domain, then open the Advanced DNS tab. Under Host Records click Add New Record and choose TXT Record. In the Host field enter _dmarc, in the Value field paste the record, and set TTL to Automatic. Namecheap uses @ for the bare domain and appends the domain to everything else, so the Host is _dmarc on its own. Click the green tick to save.

Amazon Route 53

In the AWS console open Route 53 → Hosted zones and select your domain's zone. Click Create record. Here you must enter the fully qualified name: in the Record name field type _dmarc and Route 53 will show it as _dmarc.yourdomain.com. Set Record type to TXT. In the Value box paste the record wrapped in double quotes, like "v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com", because Route 53 requires TXT values to be quoted. Set TTL to 3600 and click Create records.

Google Domains / Squarespace

Google Domains has migrated to Squarespace. Sign in to your Squarespace account, open Settings → Domains, select your domain, and open DNS Settings (or DNS → Custom records). Add a record with Type TXT, Host (or Name) _dmarc, and Data set to the record value. The host should be _dmarc only, as the domain is appended automatically. Save.

Microsoft 365 / Outlook DNS

If your DNS is hosted in Microsoft 365, sign in to the Microsoft 365 admin centre, go to Settings → Domains, select your domain, and open the DNS records tab. Choose Add record, set the type to TXT, set TXT name to _dmarc, set TXT value to the record, and TTL to 1 Hour. The name is _dmarc with no domain suffix. Note that Microsoft 365 does not always host your DNS even when it hosts your mailboxes; if your nameservers point elsewhere (check with our tools), add the record at whichever provider actually controls the zone, not in the Microsoft admin centre.

Common mistakes and gotchas

Most DMARC records that fail to work fail for one of a small handful of reasons. Run through these before you assume something exotic is wrong.

• The doubled host. Entering _dmarc.yourdomain.com at a provider that auto-appends the domain produces _dmarc.yourdomain.com.yourdomain.com. The record exists but at the wrong name, so lookups find nothing. When in doubt, enter _dmarc alone. Route 53 is the exception where you enter the full name.
• Two DMARC records. Only one _dmarc TXT record is allowed. A second one makes the policy ambiguous and receivers may ignore both. Edit the existing record rather than adding another.
• A missing or dead rua mailbox. If dmarc@yourdomain.com does not exist or bounces, your reports vanish and you have nothing to base enforcement on. Make sure the mailbox receives mail before you publish.
• Reporting across domains without authorisation. If your rua address is on a different domain (for example a third-party reporting service), that other domain must publish an authorisation record of the form yourdomain.com._report._dmarc.theirdomain.com with value v=DMARC1, or many receivers will not send the reports. Reporting to a mailbox on your own domain needs no such record.
• Smart quotes and stray characters. Copying the value from a word processor can substitute curly quotes or insert line breaks. Paste plain text. The tag separators are semicolons, and a single space after each is fine.
• Wrong record type. DMARC is always a TXT record. There is no DMARC-specific record type, and it is never a CNAME for a self-managed record.
• Expecting instant results. DNS changes propagate as caches expire, governed by the TTL. Allow up to an hour, sometimes a little longer, before checking. A lower TTL during a migration speeds up later edits.
• Treating p=none as protection. A record at p=none blocks nothing. It is a monitoring stage, not a destination. The protection only exists once you reach p=quarantine or p=reject, which is why the path to enforcement matters as much as publishing the record.

DMARC is also the foundation other controls build on. BIMI, which displays your verified logo in Gmail and Apple Mail, requires DMARC at enforcement before it works at all, and a clean DMARC posture sits alongside your SPF and MTA-STS records as part of a complete email-authentication setup. Get the record right, watch the reports, and tighten in stages, and you turn an open door into a locked one.