Free DMARC Record Checker

What is DMARC?

DMARC (Domain-based Message Authentication, Reporting, and Conformance) is an email authentication protocol that builds on top of SPF and DKIM. It allows domain owners to specify how receiving mail servers should handle emails that fail authentication checks, and provides a reporting mechanism so you can monitor who is sending email on behalf of your domain.

DMARC records are published as DNS TXT records at _dmarc.yourdomain.com. When a receiving mail server gets an email claiming to be from your domain, it looks up your DMARC record to determine the authentication policy and decides whether to deliver, quarantine, or reject the message.

How DMARC Works

DMARC works through a three-step process that ties together existing email authentication mechanisms:

1. Authentication: The receiving mail server checks the incoming email against both SPF (which verifies the sending server's IP is authorized) and DKIM (which verifies the email's cryptographic signature). At least one of these must pass for DMARC to succeed.

2. Alignment: DMARC adds a critical alignment check that SPF and DKIM alone don't provide. The domain in the visible "From" header must align with the domain authenticated by SPF or DKIM. This prevents attackers from passing SPF/DKIM with their own domain while spoofing your domain in the From header.

3. Policy enforcement: Based on the DMARC policy (p=none, p=quarantine, or p=reject), the receiving server takes the specified action on emails that fail both authentication and alignment.

DMARC Policies Explained

The p= tag in a DMARC record defines the policy that receiving servers should apply to emails that fail DMARC checks:

p=none (Monitor): This is the starting point for most organizations. No enforcement action is taken -- emails that fail DMARC are still delivered normally. The purpose is to collect reports and understand your email ecosystem before applying restrictions. This policy lets you identify all legitimate senders before tightening enforcement.

p=quarantine (Suspicious): Emails failing DMARC checks are treated as suspicious. In practice, this usually means they are routed to the recipient's spam or junk folder. This is a good intermediate step -- it protects recipients while giving you a safety net if legitimate emails are misconfigured.

p=reject (Block): The strictest policy. Emails failing DMARC are outright rejected by the receiving server and never reach the recipient. This provides the strongest protection against phishing and spoofing, but requires confidence that all legitimate email sources are properly authenticated.

The recommended approach is a gradual rollout: start with p=none to gather data, move to p=quarantine once you have verified legitimate senders, and finally upgrade to p=reject for maximum protection. Use the pct= tag to incrementally apply the policy to a percentage of your email.

DMARC and Custom Domains

For SaaS platforms that allow users to bring their own custom domains, DMARC creates an important consideration for email deliverability. When your platform sends emails on behalf of customers using their custom domains (e.g., transactional emails, notifications, or marketing emails), those emails must pass the customer's DMARC policy.

If a customer has a strict DMARC policy (p=reject) and your platform's sending infrastructure isn't properly configured in their SPF record or DKIM signing, emails sent from your platform using their domain will be rejected. This can lead to missed notifications, broken user flows, and frustrated customers.

The solution involves proper SPF configuration, DKIM signing with the customer's domain, and careful DNS record management. SaaSKevin automates web custom domain onboarding with DNS routing verification, SSL provisioning, and request routing. DMARC, SPF, and DKIM policy configuration should still be managed in your email sending infrastructure.