DMARC: Protect Your Domain Against Email Spoofing

By Mouhamed BANKOLE, CEO at ITNET Technologies · Updated November 2, 2026 · Reading time: 10 min

A customer forwards you an email "sent by you" asking for a bank transfer, or your own messages start landing in spam at Gmail and Outlook. Either way, the answer is DMARC: the DNS record that tells mailbox providers what to do with an email pretending to come from your domain. This guide explains what DMARC adds to SPF and DKIM, how to choose between the none, quarantine and reject policies, how to publish the record and read the reports, and how to move to reject without blocking your own mail. It also covers the changes in the new standard published in 2026.

In short

• DMARC protects your domain against spoofing: it asks mailbox providers to check that the visible "From" address is authenticated by SPF or DKIM.
• There are three policies: p=none (monitor), p=quarantine (send to spam) and p=reject (refuse).
• The record is a simple TXT published at _dmarc.yourdomain.com, for example v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com.
• Aggregate reports show you every day who is sending email with your domain, legitimately or not.
• Move to reject step by step, once all your sending services are authenticated: it is the only policy that actually stops spoofing.

Contents

1. What is DMARC?
2. What does DMARC add to SPF and DKIM?
3. What is DMARC alignment?
4. Which DMARC policy should you choose: none, quarantine or reject?
5. How do you create a DMARC record?
6. How do you read DMARC reports?
7. How do you move to reject gradually?
8. What changes with the new DMARC standard?
9. Why do Gmail and Outlook require DMARC?

What is DMARC?

DMARC (Domain-based Message Authentication, Reporting and Conformance) is a DNS record that tells mailbox providers how to handle an email claiming to come from your domain without being authenticated, and asks them to send you reports. It was described in RFC 7489, now replaced by RFC 9989.

DMARC does three jobs:

• authenticate: it checks that the "From" address shown to the recipient matches a domain validated by SPF or DKIM;
• decide: it tells the receiving server what to do on failure (deliver, send to spam, refuse);
• inform: it gets you reports on every email sent using your domain.

It is the piece that turns SPF and DKIM, two technical checks, into real protection against email spoofing.

What does DMARC add to SPF and DKIM?

SPF and DKIM authenticate a server or a signature, but neither protects the "From" address the recipient actually reads; DMARC ties that visible address to both checks. A fraudster can send an email that passes SPF for their own domain while displaying yours in the "From" field: without DMARC, nothing stops them.

If SPF and DKIM are not set up yet, start there: our DKIM and SPF guide walks through the configuration step by step.

What is DMARC alignment?

Alignment is the core rule of DMARC: the domain validated by SPF or DKIM must match the domain in the "From" address, and one of the two being both valid and aligned is enough for DMARC to pass. This logic is defined in RFC 7489 and carried over into RFC 9989.

There are two alignment modes, set by the aspf (SPF) and adkim (DKIM) tags:

• relaxed (r, the default): a subdomain is accepted, for example news.yourdomain.com for yourdomain.com;
• strict (s): the domain must be exactly the same.

What most often breaks alignment:

• an email marketing tool sending from its own technical domain without signing DKIM with yours;
• a website form sending from the web server without being listed in SPF;
• invoicing software or a CRM set up with your address but not your domain;
• automatic forwarding, which often makes SPF fail (DKIM survives if the message is not modified).

Which DMARC policy should you choose: none, quarantine or reject?

Always start with p=none to monitor safely, move to p=quarantine once your legitimate mail is authenticated, then finish with p=reject, the only policy that truly blocks spoofing. The p tag is defined in RFC 9989.

Two tags complete the policy:

• sp sets a different policy for subdomains (for example sp=reject if you never send from a subdomain);
• t=y (the new test mode in RFC 9989) signals that the policy is being rolled out, according to Red Sift.

Pro tip: a domain that never sends email (brand domain, old domain) still needs protecting, with v=DMARC1; p=reject and an SPF record of v=spf1 -all. Such domains are easy targets for spoofing.

How do you create a DMARC record?

Creating a DMARC record means publishing a TXT record named _dmarc in your domain's DNS zone, with at least the version, the policy and an address to receive reports. The syntax follows RFC 9989.

Step by step:

1. check SPF and DKIM: send an email to Gmail and look for "spf=pass" and "dkim=pass" in the original message;
2. create an address for reports, for example dmarc@yourdomain.com, or use an analysis service;
3. open your domain's DNS zone and add a TXT record named _dmarc;
4. enter the value v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com;
5. wait for caches to refresh (the TTL), then check with dig TXT _dmarc.yourdomain.com;
6. let it run for two to four weeks to collect representative reports.

Tags worth knowing:

Wayhost DNS management lets you create TXT records from its interface, and the professional email page has an FAQ question dedicated to SPF, DKIM and DMARC (observed on November 2, 2026 on the French pages). If reports must go to a domain other than yours, that domain has to authorize it with a specific record, as the standard requires.

How do you read DMARC reports?

Aggregate reports (rua) are XML files usually sent daily by the major mailbox providers; for each sending IP address they list how many emails arrived using your domain and the SPF, DKIM and DMARC results. Their format is now described in RFC 9990, according to Red Sift.

What to look for:

• legitimate sources that fail: your mailbox provider, marketing tool or website failing alignment, to fix first;
• unknown sources: IP addresses you do not recognize sending with your domain, a sign of spoofing or a forgotten service;
• volume per source, to spot a service sending more than expected;
• forwarded messages, which often fail SPF without being fraudulent.

Raw XML reports are hard to read: an analysis tool turns them into tables by source. Failure reports (ruf) give message-by-message detail, but some providers do not send them for privacy reasons.

How do you move to reject gradually?

Moving to reject happens in stages: monitor with none, fix every legitimate source, switch to quarantine, then to reject, checking reports at each step. Skipping steps is the most common cause of legitimate emails being blocked.

A realistic timeline for a small business:

1. weeks 1 to 4: p=none, inventory every sending source using the reports;
2. as you go: add each legitimate service to SPF and enable DKIM with your domain;
3. once reports are clean: p=quarantine, optionally with t=y while you verify;
4. two to four weeks later: p=quarantine without test mode;
5. goal: p=reject, then monthly report monitoring.

Before each step, check:

• your main mailbox and shared mailboxes;
• marketing tools (newsletters, follow-ups);
• transactional emails from your site or shop, often sent by the web hosting itself;
• business software (invoicing, CRM, booking).

Pro tip: the pct tag, used until now to apply the policy to only part of the traffic, is removed in the new standard according to Red Sift. For a gradual rollout, rely on t=y and the none, quarantine, reject stages instead.

What changes with the new DMARC standard?

In 2026, DMARC became an IETF Proposed Standard: RFC 9989 replaces RFC 7489, and two separate RFCs cover reporting. According to Red Sift, these documents were published in May 2026.

The main changes, according to Red Sift:

• pct removed: the policy applies to all traffic, and the t=y / t=n test mode takes over;
• rf and ri removed, as they were rarely used;
• no more Public Suffix List: the organizational domain is now found by walking the DNS tree;
• new psd tag for special cases of organizational domains and subdomains;
• separate reporting specs: aggregate in RFC 9990, failure in RFC 9991.

What it means for you: an existing record remains valid and does not need to be republished, according to Red Sift. Just remove pct if you rely on it long-term, and do not stay on p=none forever.

Why do Gmail and Outlook require DMARC?

Gmail and Outlook require DMARC from bulk senders to fight spoofing and spam, and a domain without DMARC sees its deliverability suffer, even for small volumes. Gmail requires DMARC from senders of more than 5,000 messages a day to personal accounts, with an aligned "From" domain, according to its email sender guidelines.

What the two big providers require:

• Gmail: SPF or DKIM for all senders, and SPF, DKIM and DMARC for bulk senders, with a spam rate kept below 0.3% (Google guidelines);
• Outlook.com, Hotmail and Live: since May 5, 2025, SPF, DKIM and DMARC for domains sending more than 5,000 emails a day, with non-compliant messages first routed to junk and later rejected, according to IT-Connect;
• other providers are gradually adopting the same practices.

Even below these thresholds, publishing DMARC is a trust signal for filters and protects your customers from fake emails in your name. For the full picture, from address to mailbox, see our professional email guide.

Frequently asked questions

What is DMARC in a nutshell?

DMARC is a DNS record that tells mailbox providers what to do with an email pretending to be from your domain without being authenticated. It builds on SPF and DKIM and checks the visible "From" address. It also sends you reports about emails sent using your domain.

Do you need SPF and DKIM to set up DMARC?

Yes, DMARC relies on at least one of them, ideally both. A message passes DMARC if SPF or DKIM is valid and aligned with the "From" address. Without SPF or DKIM, a strict policy would block your own emails.

What is the difference between p=quarantine and p=reject?

With quarantine, a failing email is usually placed in the recipient's spam folder. With reject, it is refused and never arrives. Reject protects better, but requires every sending service to be properly authenticated.

How long should you stay on p=none?

Long enough to receive representative reports, usually two to four weeks. You then need to fix every failing legitimate source before tightening the policy. Staying on none forever does not protect your domain.

How do you check your DMARC record?

Run dig TXT _dmarc.yourdomain.com or use an online checker. You can also view the original of an email received in Gmail, which shows the DMARC result. The record must start with v=DMARC1.

Does DMARC stop phishing?

DMARC stops exact spoofing of your domain in the "From" address, provided it is set to quarantine or reject. It does not block lookalike domains or emails sent from free mailbox addresses. User awareness is still needed.

Is my DMARC record still valid under RFC 9989?

Yes, an existing record remains valid and does not need to be republished. The pct tag is no longer defined by the new standard, so it is best to remove it if you rely on it long-term. The t=y test mode replaces it for gradual rollouts.

Does a small business need DMARC?

Yes, because spoofing also targets small organizations, especially for payment fraud. DMARC also improves deliverability with Gmail and Outlook. Setting it up takes one DNS record and a few weeks of monitoring.

Key takeaways

• DMARC protects the "From" address your customers read, which SPF and DKIM cannot do alone.
• Alignment is the key: SPF or DKIM must validate the same domain as the visible address.
• Start with p=none to inventory your sending sources through reports.
• Aim for p=reject in stages, once every legitimate service is authenticated.
• RFC 9989 replaces RFC 7489: drop pct and use the t=y test mode.

To send email in your own name with a clean setup, explore Wayhost professional email.

Article written by Mouhamed BANKOLE, CEO at ITNET Technologies.