DMARC: fake email protection

DMARC (Domain-based Message Authentication, Reporting, and Conformance, defined in RFC 7489) is the public setting on your domain that tells inboxes what to do when an email claims to come from you, and where to send daily reports about who is using your domain.

Without DMARC, each receiving mail provider has to guess how to handle messages that fail SPF or DKIM. DMARC puts you in control: instead of trying to filter out bad mail after the fact, you give every inbox a clear rule to filter in legitimate mail from your domain and quarantine or block fakes.

Inboxes will only display your BIMI logo and blue verified checkmark when your DMARC policy is set to enforcement: either p=quarantine (at 100%) or p=reject.

Why DMARC matters#

• Stops spoofing and phishing: Protects your customers and team from attackers forging @yourcompany.com in the From: line (such as fake invoices or password-reset scams).
• Full visibility (including "Shadow IT"): Receiving servers (Gmail, Yahoo, Outlook, Apple Mail) email you daily XML summaries showing every IP address and service sending mail as your domain, and whether each one passed SPF and DKIM.
• Better deliverability and compliance: Gmail and Yahoo require DMARC for bulk senders (5,000+ messages per day), and an enforced DMARC policy is required for VMC and CMC mark certificates.

How DMARC and alignment work#

DMARC builds on top of SPF and DKIM. You must set up SPF and/or DKIM before enforcing DMARC.

The "at least one aligned pass" rule#

To pass DMARC, an email must pass at least one of these two checks:

1. SPF authentication + SPF alignment: The sending server passes SPF, and the envelope Return-Path (MAIL FROM) domain matches the visible From: header domain.
2. DKIM authentication + DKIM alignment: The message has a valid DKIM-Signature, and the signing domain (d=) matches the visible From: header domain.

A message only fails DMARC if both aligned SPF and aligned DKIM fail. This is why setting up both SPF and DKIM is best practice: when a recipient auto-forwards your email to another inbox, SPF usually fails (because the forwarder's IP is not in your SPF record), but your DKIM signature survives and the message still passes DMARC.

Relaxed vs. strict alignment (aspf and adkim)#

DMARC supports two alignment modes for comparing the From: domain (yourcompany.com) against the SPF Return-Path domain or DKIM d= domain:

Keep relaxed alignment (r, the default) unless you have a specific reason not to. Many email providers (Postmark, Amazon SES, Resend, SendGrid) use a custom subdomain for the Return-Path bounce address; setting aspf=s will cause those messages to fail SPF alignment. Only use strict alignment (s) if untrusted third parties operate subdomains under your main domain.

Before you begin#

1. Turn on SPF and DKIM first. If you enforce DMARC before SPF or DKIM is authenticating your mail, your own messages will be sent to spam or rejected. On an active domain, Google Workspace recommends letting SPF and DKIM run for at least 48 hours before tightening DMARC.
2. Create a dedicated mailbox or group for DMARC reports (rua=). Active domains receive multiple XML report emails every day (large domains can receive hundreds). Use a dedicated address such as dmarc@yourcompany.com (or a DMARC reporting service) rather than your personal inbox. The mailbox must exist and your domain must be able to receive email, or the reports are lost. In the VerifiedInbox Email security step, every suggested record uses the address in your current record, or dmarc@ your main domain; choose Use a different address to change it in all of them at once.

How VerifiedInbox uses DMARC#

• The Email security step asks who sends email from your domain. Not yet and Only from our mailbox get the blocking record right away; From several tools gets the four-stage rollout below.
• To continue past that step, DMARC must be published in watch mode (p=none) or stronger, with a report address. You don't have to wait for the whole rollout.
• By the DNS step, DMARC must be at enforcement (p=quarantine at 100% or p=reject). We check again right before ordering your certificate.
• Suggested records keep the extra tags of your current record (such as ruf, strict adkim or aspf). We remove sp=none and say so, because BIMI requires your subdomains to be protected too.

New domains without DMARC#

If your domain is brand new, sends no email yet, or only uses a single mailbox provider with no third-party mailing tools, you do not need a multi-week rollout:

1. Configure SPF and DKIM for your mailbox provider.
2. Publish a strict DMARC enforcement record right away at _dmarc:

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

Because no unauthenticated services are sending mail from your domain, going straight to p=reject protects your brand immediately and satisfies the DMARC requirement for your BIMI inbox logo on day one.

If your domain already sends business email every day across multiple tools (newsletters, CRM, billing, helpdesk) and currently has no DMARC record, follow the staged rollout below so you do not accidentally filter your own messages.

How DMARC quarantine works, how to configure it, and how to troubleshoot#

What quarantine does#

Your DMARC policy (p=) has three possible settings:

• p=none (Monitor only): Takes no action on failing mail; delivers messages normally and sends daily XML reports to your rua= address so you can see who is sending as your domain.
• p=quarantine (Send fakes to spam): Instructs Gmail, Outlook, Yahoo, and other inboxes to move any email that fails DMARC into the recipient's spam or junk folder instead of the primary inbox.
  • Unlike p=none, p=quarantine actively protects recipients from fake emails.
  • Unlike p=reject, a legitimate message sent from a misconfigured tool is still recoverable from the recipient's spam folder while you fix that sender's SPF or DKIM settings.
  • Once p=quarantine applies to 100% of messages (when pct is omitted or set to pct=100), your domain meets the DMARC enforcement requirement for BIMI and your VMC or CMC certificate.
• p=reject (Block fakes outright): Instructs receiving servers to drop failing messages at the SMTP door before they ever reach the inbox or spam folder. This is the strongest protection for your brand.

Configuring a safe rollout to quarantine and reject#

For active domains, tighten DMARC in four stages (safe DMARC rollout):

Stage 1: Watch#

Stage 2: Quarantine 25%#

Stage 3: Quarantine 100%#

Stage 4: Reject all (recommended)#

Reading DMARC reports and troubleshooting quarantine issues#

As daily rua= reports arrive (or when you test a message during quarantine), every sender falls into one of three buckets:

1. Known, aligned sources: Services you use where DKIM and/or SPF pass and align with your domain. No action needed.
2. Unconfigured legitimate sources ("Shadow IT"): A tool your team uses (such as a helpdesk, billing system, or marketing platform) that is sending as @yourcompany.com without aligned DKIM or SPF.
   • Fix DKIM first: Enable custom domain DKIM signing in that tool's dashboard so its DKIM-Signature uses d=yourcompany.com (rather than a shared domain like d=sendgrid.info).
   • Fix SPF alignment: Add the provider's include: to your SPF record and configure their custom Return-Path subdomain so the bounce domain aligns with yourcompany.com.
3. Forwarded mail and spoofers:
   • If DKIM passes and aligns while SPF fails, the email was almost certainly auto-forwarded by a recipient; DMARC still passes.
   • Unknown IPs where both SPF and DKIM fail in small numbers (or obvious spam campaigns) are the exact spoofers DMARC is designed to quarantine and block.

If legitimate emails land in spam after you enable p=quarantine, open a message in Gmail via More → Show original (or send a test email from the VerifiedInbox Email security or Go live step) to inspect the Authentication-Results header. If you need time from another department to add a DKIM key, you can temporarily lower pct=25 or step back to p=none, then return to p=quarantine or p=reject once fixed.

Keep monitoring your rua= reports even after reaching p=reject: if someone later adopts a new email tool without configuring DKIM, p=reject will block that tool's emails until you authorize it.

Technical reference: DMARC syntax and example records#

A DMARC record is published as a single TXT record at _dmarc.<yourdomain.com>. Tags are separated by semicolons (;). v=DMARC1 must be the first tag, and p= must be the second tag; all other tags may appear in any order.

Tags#

Example records#

Stage 1 monitoring (with two report recipients):

v=DMARC1; p=none; rua=mailto:dmarc@yourcompany.com, mailto:postmaster@yourcompany.com

Standard enforcement with quarantine (BIMI-ready):

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

Strict enforcement for the domain and all subdomains (recommended target state):

v=DMARC1; p=reject; sp=reject; adkim=r; aspf=r; rua=mailto:dmarc@yourcompany.com

Common issues & edge cases#

• Sending rua= reports to a different domain without External Report Authorization. By default, receiving servers only send rua= reports to addresses on the same domain as the DMARC record (for example mailto:dmarc@yourcompany.com for yourcompany.com). If you send reports to an external domain (such as mailto:reports@dmarc-vendor.com), the external domain must publish a DNS TXT record at yourcompany.com._report._dmarc.dmarc-vendor.com with the value v=DMARC1. Without that authorization record, receivers silently drop your rua= address.
• Omitting mailto: on a second rua= address. When listing multiple report addresses, every address needs its own mailto: prefix, separated by a comma: rua=mailto:dmarc@yourcompany.com, mailto:ops@yourcompany.com. Writing rua=mailto:dmarc@yourcompany.com, ops@yourcompany.com is a syntax error.
• Using strict SPF alignment (aspf=s) with a provider that uses a return-path subdomain. Many providers (Postmark, Amazon SES, Resend, SendGrid) send bounces to a subdomain like pm-bounces.yourcompany.com. Under aspf=s, that subdomain does not match yourcompany.com and SPF alignment fails. Leave aspf=r (the default) so subdomains align properly.
• Leaving p=none in place. v=DMARC1; p=none only monitors; inboxes will not display a BIMI logo until p=quarantine (with pct=100) or p=reject is live.
• Setting pct below 100 or sp=none. The BIMI specification requires pct=100 (or no pct tag) on your domain and forbids sp=none on the organizational domain. If you omit sp=, subdomains automatically inherit your p=quarantine or p=reject policy.
• Two _dmarc TXT records. A domain may only have one TXT record starting with v=DMARC1 at _dmarc. If two _dmarc records exist, receivers ignore DMARC altogether.
• Putting p= anywhere other than right after v=DMARC1;. The DMARC specification requires v=DMARC1 to be the first tag and p=... (or sp=...) to follow immediately as the second tag.
• Duplicated domain name in the Host field. Some DNS providers automatically append .yourcompany.com to whatever you type in the Host field. If you enter _dmarc.yourcompany.com, it may create _dmarc.yourcompany.com.yourcompany.com. VerifiedInbox checks your authoritative nameservers directly and warns you if this happens.