Get Support Sign in →
LochStudios  /  Help Centre  /  Email Deliverability  /  DMARC Explained and How to Set It Up

DMARC Explained and How to Set It Up

What a DMARC policy does, how to publish the TXT on AtlasDNS or in cPanel, and how to tighten it after SPF and DKIM are working.

Updated

DMARC (Domain-based Message Authentication, Reporting and Conformance) is a TXT record on _dmarc. It tells receiving inboxes what to do when a message claims to be from your domain but does not pass SPF or DKIM alignment. It also sends you reports so you can see who is sending as that name.

We publish this with you. Unsure which product or DNS mode you are on? Open a support ticket and we will set the record.

DMARC is the third authentication record. Set SPF and DKIM first. One DMARC row covers the From domain, no matter which of our mail products sends.

Why it matters

SPF lists who may send. DKIM signs the message. DMARC ties those checks to the domain in the From address.

  • Spoofed mail that fails alignment can be held or not accepted, instead of landing in the inbox.
  • You choose the policy: monitor only, send failures to spam, or ask receivers not to accept the message.
  • Aggregate reports show legitimate senders and anything else using the domain.
  • Inboxes treat a domain with a published policy as more trustworthy. See Why your emails go to spam.
  • Large inboxes (Gmail, Yahoo, and similar) expect a DMARC record from domains that send a lot of mail.

How a check works

  1. You publish one TXT record at _dmarc.yourdomain.com.
  2. The record names a policy (none, quarantine, or reject) and, usually, an address for reports.
  3. When a message arrives with your domain in From, the receiving server asks:

- Did SPF or DKIM pass?
- Does the domain in that pass match the From domain (alignment)?

  1. If alignment fails, the receiver follows your policy.
  2. That receiver can send you a daily aggregate report.

Alignment means the domain that passed SPF or DKIM is the same organisational domain as From. Mail from news@yourdomain.com must pass as yourdomain.com (or a subdomain you have allowed), not as an unrelated name.

The three policies

Start at the weakest and tighten after the reports look clean.

p=none - Monitor only. The message is still delivered. You get reports. Use this until every real sender passes SPF or DKIM alignment.

p=quarantine - Unauthenticated mail is treated as spam. Move here once the reports show your own mail passing.

p=reject - The receiving server does not accept the message. Use this only after you have watched quarantine for a while and every legitimate sender still passes.

Do not start at p=reject. A missing DKIM selector or an extra newsletter tool will stop that mail from arriving.

Before you publish DMARC

DMARC does nothing useful if SPF and DKIM are missing or unsigned.

  • Add and test SPF.
  • Enable DKIM on the product that actually sends.
  • Send a test from each address you use (including no-reply and any newsletter tool).

Which mail product signs and sends:

  • Shared hosting (mailboxes you create in cPanel): SPF and DKIM from cPanel Email Deliverability. See Create an email account.
  • LochStudios Mail (hosted business email): copy SPF and DKIM from the mail service in the portal. Open that service and use Log in to WebMail for the inbox. See What is Axigen webmail and how to sign in.
  • Another sending system (a newsletter tool, a CRM, or mail that is not hosted here): they must appear in your one SPF string and publish their own DKIM selector. Paste their records as written.

Do not mix those paths. A cPanel key will not sign LochStudios Mail, and the other way around. DMARC still sits on the From domain either way.

What the record looks like

A first record should look like this:

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

Tags:

  • v=DMARC1 - Version. Always first.
  • p=none - Policy. Start here.
  • rua=mailto:dmarc@yourdomain.com - Where aggregate reports go. Use a mailbox you read, on this domain.

Later, when you tighten:

v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com; ruf=mailto:dmarc@yourdomain.com; fo=1
  • ruf=mailto:... - Address for forensic (per-message) reports when authentication fails. Optional. Receiving inboxes often skip these.
  • fo=1 - Ask for a forensic report when both SPF and DKIM fail.
  • sp=quarantine or sp=reject - A different policy for subdomains. Optional.

Create the report address first so mail can be delivered there. On shared hosting, create the mailbox. On LochStudios Mail, add it on that service. A dedicated address such as dmarc@yourdomain.com keeps the reports out of your day-to-day inbox.

Where the TXT record goes

The name is _dmarc. AtlasDNS is the default. Do not send the domain to a third-party DNS host.

  1. Sign in at /portal.
  2. Open Domains, then the domain, then DNS.
  • AtlasDNS (the usual case): add the TXT on that page. When the domain uses AtlasDNS, the nameservers are:
ns1.atlasdns.net.au
ns2.atlasdns.net.au
ns3.atlasdns.net.au
  • cPanel Hosting DNS mode (the domain is paired with a shared hosting service): the portal says records are managed from the hosting control panel. Open the hosting service, click Log in to cPanel, and add the TXT in the Zone Editor. Some cPanel Email Deliverability screens also suggest a DMARC value; if you use that, do not also paste a second _dmarc row.

Unsure which mode you are on? Open a support ticket.

Add the record:

  1. Create a TXT record.
  2. Set the name to _dmarc (or _dmarc.yourdomain.com only if the form asks for the full name).
  3. Paste the DMARC string as the value, starting at v=DMARC1.
  4. Save.
TypeNameValue
TXT_dmarcv=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com

On AtlasDNS the name field is the left-hand label (_dmarc), not the full _dmarc.yourdomain.com, unless the form asks for the FQDN.

Publish one DMARC record for the domain. Two different TXT values on _dmarc confuse receivers.

Record types: DNS record types explained.

Check that it is live

DNS changes are often quick. They can take a while to show everywhere. See DNS propagation explained.

Look up the published record (use your real domain):

nslookup -type=TXT _dmarc.yourdomain.com

You should see the same v=DMARC1 string you saved.

If you would rather we check, open a support ticket and include the domain and the policy you intended.

Read the reports, then tighten

For the next few days to weeks you should receive aggregate reports (XML attachments) at the rua address. They show:

  • Which hosts sent mail as your domain
  • Whether those messages passed SPF and DKIM
  • Volume from systems you do not recognise

Keep p=none until every sender you care about passes. Then:

  1. Change p=none to p=quarantine.
  2. Watch delivery for a week.
  3. If your own mail still arrives, change the policy to p=reject.

If a real sender fails after you tighten, move the policy back to p=none (or p=quarantine), fix that sender's SPF or DKIM, and try again.

Subdomains

By default the organisational policy also applies to subdomains. You can set a different one with sp=:

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

That asks receivers not to accept unauthenticated mail for yourdomain.com, while only monitoring mail.yourdomain.com (and other subdomains). Use this when a subdomain has senders the root name does not.

A subdomain that sends as itself still needs its own SPF and DKIM. Addresses that send as the root domain use the root records.

Keep mail, website, and authentication records on AtlasDNS (or on cPanel Hosting if that is the live mode). See Point your domain at your hosting.

Good habits

  • Start at p=none. Move none → quarantine → reject over weeks, not in one save.
  • Use a mailbox you control for rua (and ruf if you set it).
  • Open the reports regularly so a new sender does not surprise you after you tighten.
  • Keep the From domain aligned with the SPF and DKIM domain.
  • Set sp= only when subdomains really send differently.
  • One _dmarc TXT. Edit the existing row when you change policy; do not add another.

BIMI (a logo in some inboxes) is a later step. It needs a working p=quarantine or p=reject policy first. We can talk through that in a ticket if you want it.

If something looks wrong

No reports arrive. The rua mailbox must exist and accept mail. Confirm MX still points at the product that hosts that address. Some receivers send reports only after they have seen traffic.

Your own mail is treated as spam after p=quarantine. That sender is not passing SPF or DKIM alignment. Fix that product first (or add its DKIM selector). Do not jump to p=reject. If you need the policy loosened while we sort it, open a support ticket.

The policy seems to do nothing. Confirm you are editing the live zone (AtlasDNS versus cPanel Hosting). Wait for propagation. Look up _dmarc and confirm there is only one TXT.

The lookup says the record is invalid. v=DMARC1 must be first. Separate tags with semicolons. Report addresses must use mailto:. Do not wrap the value in quotes unless the DNS form adds them for you.

More than one sending system. Each needs SPF (merged into the single SPF string) and its own DKIM selector. DMARC will fail that From address until both are in place.

If mail still does not authenticate after the lookup looks right, open a support ticket. Include the domain, the mail product, and a recent _dmarc lookup.

Next steps

Once p=reject is live and reports stay clean, the domain is in good shape against spoofing. Keep watching rua when you add a new sender. We can set SPF, DKIM, and DMARC together if you open a support ticket.

If mail is not arriving at all, start with Email is not sending or receiving.

Related

Was this article helpful?

← Back to Email Deliverability