Quick answer
Your domain has no DMARC record. Receiving mail servers have no policy from you telling them what to do when SPF or DKIM fails to align with your visible From address. The From domain is easier to spoof, Google and Yahoo now require bulk senders to publish at least p=none, and Microsoft has announced equivalent requirements. Publish a starter p=none record after confirming SPF and DKIM are in place. Do not skip straight to p=reject.
What a missing DMARC record means
DMARC is a DNS TXT record published at _dmarc.<yourdomain>. The record starts with v=DMARC1 and tells receiving mail servers two things: what to do with mail that fails DMARC alignment, and where to send aggregate reports about what is passing and failing across your domain.
When no record exists at that location, the DMARC lookup returns nothing. Receiving servers have no explicit policy from your domain to apply. They cannot quarantine or reject misaligned mail on your behalf, and they cannot send you aggregate reports about who is sending as your domain. The visible From address is easier to use in spoofed or phishing messages because there is no published organizational policy for receivers to enforce.
Spoofing attacks commonly target domains with no DMARC record or a p=none monitor-only policy. Your domain does not need to be a high-profile brand to be worth spoofing. Any domain that has sent payment requests, vendor correspondence, or account-related mail is a target.
Beyond spoofing exposure, the operational consequences have changed. Google's sender guidelines require bulk senders (roughly, domains sending 5,000 or more messages per day to Gmail users) to publish at minimum a p=none DMARC record. Yahoo Mail has parallel requirements. Microsoft has announced equivalent enforcement for its hosted mailboxes. For higher-volume senders, a missing DMARC record is no longer a configuration gap. It can directly cause your mail to be rejected or routed to spam before any reputation signal is considered.
Why DMARC needs SPF and DKIM to already be working
DMARC does not check authentication independently. It checks alignment: whether a domain that already passed SPF or DKIM is the same organizational domain as the visible From address in the message.
That ordering matters. If SPF fails or DKIM is unsigned, there is nothing for DMARC to align. Publishing a DMARC record, especially an enforcing policy like p=quarantine or p=reject, before your sending paths authenticate correctly will cause your own legitimate mail to fail DMARC. That outcome is worse than no policy at all.
Verify SPF is passing and authorized for every platform that sends as your domain. Verify DKIM is signing correctly for every platform. Only then publish DMARC, starting at p=none so you can observe reports without enforcement risk while you confirm the authenticated picture matches the real sending inventory.
How to diagnose a missing DMARC record
Check the TXT records at _dmarc.<yourdomain>. From the command line:
nslookup -type=TXT _dmarc.yourdomain.com
Or on a system with dig:
dig TXT _dmarc.yourdomain.com
A domain with a valid DMARC record returns a TXT entry starting with v=DMARC1. A domain with no DMARC record returns no answer or a response with no v=DMARC1 string. Either the record is present or it is not.
One subdomain behavior is worth noting before you proceed. Under DMARC's organizational-domain model described in RFC 7489 section 6.6.3, a subdomain with no _dmarc record of its own inherits the organizational domain's policy. If yourdomain.com has a DMARC record and mail.yourdomain.com does not, the subdomain is not unprotected. It inherits the organizational-domain policy and the sp= subdomain-policy tag if one is present. The problem this page addresses is when the organizational domain itself has no DMARC record. In that case, subdomains have nothing to inherit.
How to fix a missing DMARC record
-
Confirm SPF is correct first. Your domain must have exactly one SPF TXT record that authorizes every legitimate outbound sender. Every platform that sends as your domain must appear in that record.
-
Confirm DKIM is signing correctly for every sending platform. Each sending platform must have a valid public key published in DNS and must be configured to sign outbound messages with that key under your From domain. A DNS key alone is not enough — the platform must be actively signing.
-
Publish a starter DMARC record. Once SPF and DKIM are verified, add a TXT record at
_dmarc.<yourdomain>with the following value as a starting point:v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.comReplace
dmarc-reports@yourdomain.comwith a real mailbox that someone on your team will read. Thep=nonepolicy requests no enforcement action. Mail that fails DMARC will still be delivered, but aggregate reports start flowing so you can see the real sending picture. -
Verify the rua mailbox exists and is monitored. Aggregate reports arrive as daily XML email attachments. They show every source that sent mail claiming to be from your domain and whether each source passed SPF and DKIM alignment. If the
ruaaddress belongs to a different domain than the one you are protecting, that receiving domain needs its own DMARC external-reporting authorization record at<yourprotecteddomain>._report._dmarc.<ruadomain>. Google's DMARC setup documentation explains this step for Google Workspace. -
Read the reports and resolve misaligned senders. Let reports accumulate for at least two to four weeks. For every source that appears failing DMARC alignment, either configure that sender to authenticate under your domain or stop using it to send as your domain. Common sources that show up misaligned include marketing automation platforms, CRMs, helpdesk tools, and forgotten transactional-email integrations.
-
Progress toward enforcement only after the inventory is clean. Once reports confirm that all legitimate senders are passing alignment consistently, you can move toward
p=quarantineand eventuallyp=reject. That progression is covered in the companion guide on moving from p=none to reject.
Do not rush step 6. A p=reject policy applied before the sender inventory is complete will silently block legitimate mail (transactional receipts, password-reset messages, CRM emails) with no easy recovery path for recipients who never receive them.
What this does not prove
Checking whether a DMARC record exists and verifying that its syntax is valid tells you what policy your domain has published in public DNS. It tells you nothing about whether receiving mail servers are currently accepting or rejecting your mail, what your domain's reputation looks like at any specific mailbox provider, whether a specific message was delivered to the inbox, or whether the rua reports arriving in the nominated mailbox show a clean picture.
A DMARC record published at p=none with a valid rua address gives you the instrumentation to learn what is happening. It does not fix anything on its own. Relaymetry checks the public DNS baseline. It cannot see inbox-placement outcomes, sender-reputation data, or the aggregate-report data arriving in your nominated mailbox.