Can Someone Pretend to Email Your Customers?

DMARC (Domain-based Message Authentication, Reporting and Conformance) is a DNS-based standard that allows a domain owner to publish a policy instructing receiving mail systems what to do with email that fails authentication. It works with SPF and DKIM to reduce email spoofing and provides reporting so domain owners can see who is sending email on their behalf.

SPF (Sender Policy Framework) is a DNS record that lists the mail servers and services authorised to send email for your domain. When a receiving mail server receives an email claiming to come from your domain, it checks the SPF record to see whether the sending server is on the approved list. If not, the SPF check fails.

DKIM (DomainKeys Identified Mail) adds a digital signature to outgoing emails. The signature is generated using a private key and can be verified using a public key published in your DNS. It allows receiving mail systems to confirm that the email was sent by an authorised server and has not been altered in transit.

SPF checks whether the sending server is authorised. DKIM checks whether the message has been altered. DMARC ties them together by requiring alignment between the visible From address and the authenticated domain, and by defining a policy for what to do when checks fail. Each one addresses a different gap. Together they provide substantially better protection than any one alone.

Yes. Without DMARC (and ideally SPF and DKIM), there is nothing to prevent a receiving mail system from accepting an email that claims to come from your domain but was sent from a completely different server. With SPF and DKIM published but no DMARC policy, the authentication data is available but there is no instruction to act on it. DMARC provides the policy that causes receiving servers to quarantine or reject failing messages.

DMARC can help prevent phishing emails that use your exact domain in the From address — if the receiving mail system checks and enforces DMARC policies. It does not prevent phishing from look-alike domains (e.g. yourcompany-support.com or yourcompany.net), phishing from compromised accounts, or phishing from entirely different domains that have no relation to yours.

No. DMARC is an authentication standard, not an encryption standard. It verifies that an email came from who it claims to be from. It does not protect the content of the email from being read in transit. Email encryption is a separate consideration — typically handled by TLS for transport-layer encryption and S/MIME or PGP for end-to-end content encryption.

Generally yes. Mail systems use authentication signals as part of their inbox placement decisions. A domain with properly configured SPF, DKIM and DMARC is a more trusted sender. Legitimate email from authenticated domains is more likely to reach the inbox rather than spam. For bulk email senders, major providers including Google and Microsoft now require or strongly recommend authentication.

Yes, for any domain used to send business email. Even a domain that never sends email should have a DMARC record — at minimum a p=reject policy tells receiving servers that no legitimate email will ever come from that domain, preventing it from being used for spoofing.

p=none is the monitoring-only DMARC policy. It tells receiving mail systems to take no action on emails that fail DMARC authentication — deliver them as normal — but to send aggregate reports back to the reporting address you specify. It is the recommended starting point: it allows you to see what is sending email on behalf of your domain without risking disruption to legitimate email.

p=quarantine instructs receiving mail systems to place emails that fail DMARC authentication in the recipient’s spam or junk folder rather than the inbox. It is an intermediate step between monitoring (p=none) and full enforcement (p=reject). It reduces the impact of spoofed email reaching inboxes while allowing false positives to be reviewed from the spam folder.

p=reject instructs receiving mail systems to block emails that fail DMARC authentication entirely. They are not delivered to the inbox or spam — they are discarded. This provides the strongest protection against spoofing but must only be set after thorough monitoring and configuration, as any legitimate sending services that are not correctly configured will also be blocked.

Yes, if set to quarantine or reject before all legitimate sending services are properly configured. If a third-party service — a CRM, marketing platform, invoicing tool or website form — sends email using your domain but is not included in your SPF record or does not sign with DKIM, a reject policy will cause its emails to be blocked. This is why starting with p=none and reviewing reports before tightening the policy is essential.

DMARC aggregate reports are XML files sent by receiving mail systems to the reporting address in your DMARC record. In raw form they are not easy to read. Several services — both free and paid — parse and visualise these reports, making it straightforward to see which servers are sending email on behalf of your domain and whether they are passing authentication.

Yes. Microsoft recommends configuring SPF, DKIM and DMARC for all domains used with Microsoft 365. Microsoft 365 checks DMARC records for inbound email and uses the results as part of its filtering decisions. Microsoft Defender for Office 365 also incorporates authentication results in its threat assessment.

Yes. Google has published requirements for senders of bulk email to Gmail: SPF or DKIM authentication is required, and DMARC is strongly recommended. Google uses DMARC signals in its inbox placement decisions. Google also offers Postmaster Tools, which provide visibility into delivery rates, spam rates and authentication for high-volume senders.

Partially. DMARC helps prevent criminals from using your exact domain to send fraudulent email. It does not prevent Business Email Compromise (BEC) that involves compromising a genuine email account within your organisation, using a look-alike domain, or attacking your suppliers or customers rather than impersonating your domain directly. BEC prevention requires multi-factor authentication, staff awareness training and email monitoring alongside DMARC.

Cyber Essentials does not explicitly require DMARC as a named control — it focuses on five key areas: firewalls, secure configuration, access control, malware protection and patch management. However, NCSC guidance strongly recommends email authentication including DMARC as part of good email security practice. Implementing DMARC demonstrates that a domain is actively managed and that email security has been considered.

The initial DNS records — SPF, DKIM and DMARC with p=none — can typically be published in a few hours. The monitoring phase — reviewing reports and ensuring all legitimate sending services are correctly configured — usually takes several weeks. Moving to a quarantine or reject policy should only happen after sufficient monitoring to be confident all legitimate email will continue to be delivered.

A receiving mail server that checks DMARC and encounters an email that fails authentication against a domain with p=reject will discard the email. It is not delivered to the inbox or spam. The sender receives a delivery failure notification. For the recipient, the fraudulent email simply never arrives.

Yes, provided they are correctly configured. Marketing platforms — Mailchimp, Campaign Monitor, HubSpot and others — send email on behalf of your domain. For DMARC to work correctly, each platform must be either included in your SPF record or configured to sign email with DKIM using your domain. Most major platforms support this. Failure to configure it is a common cause of DMARC-related email delivery problems.

DMARC alignment requires that the domain in the visible From address matches the domain used in the SPF check or the DKIM signature. This is what closes the gap that allows a message to pass SPF or DKIM while still displaying a spoofed From address. Alignment can be relaxed (subdomains are permitted) or strict (exact match required). Relaxed alignment is appropriate for most businesses.

Yes, in specific circumstances. If a criminal sends a fraudulent invoice appearing to come from your domain to a recipient whose mail system checks and enforces DMARC policies, the email will be quarantined or rejected. DMARC does not prevent invoice fraud involving compromised email accounts, look-alike domains, or recipients whose mail systems do not enforce DMARC.

Ask your IT provider to review your DNS records and confirm whether SPF, DKIM and DMARC are published. If not, the first step is to publish DMARC with p=none and a reporting address, alongside correct SPF and DKIM records. Then review the reports over several weeks before considering a stricter policy.

Subdomains used to send email need their own SPF and DKIM configuration. DMARC policy can be applied to subdomains using the sp= tag in the parent domain’s DMARC record. Subdomains that do not send email should be covered by a reject policy to prevent them from being used for spoofing.

DMARC aggregate reports (rua reports) are XML files sent by receiving mail systems — Google, Microsoft, Yahoo and others — to the email address specified in your DMARC record. They summarise all email that was received claiming to be from your domain: which servers sent it, which authentication checks passed or failed and how many messages were involved. They are sent daily and are invaluable for understanding your email environment and identifying configuration issues.

DMARC aggregate reports show all email that claims to come from your domain, including email sent by third parties using your domain without authorisation. Reports showing unfamiliar servers sending on your behalf are an important reason to review your authentication configuration and consider moving to a stricter policy.

No. DMARC only protects your specific domain. A criminal who registers yourcompany-support.com or yourcompanу.com and configures DMARC on that domain can send authenticated email from it that DMARC cannot detect as fraudulent. Protecting against look-alike domains requires domain monitoring, brand protection services and user awareness.

DMARC authentication is typically applied by receiving mail servers to inbound email. Internal email — between accounts on the same Microsoft 365 or Google Workspace tenancy — may be handled differently depending on the platform configuration. DMARC is most relevant to email sent externally from your domain to other organisations or consumers.

SPF LIMITS: SPF records are subject to a ten DNS lookup limit during evaluation (RFC 7208). Each include: mechanism that itself performs lookups counts toward this limit. Macros can help reduce lookups. Exceeding the limit causes a PermError, which results in SPF failure. Use an SPF flattening service or carefully manage mechanisms to stay within limits. A domain must have exactly one SPF TXT record; multiple records cause SPF to fail with PermError.

DKIM CONFIGURATION: DKIM private keys should be 2048-bit RSA or Ed25519. Keys should be rotated periodically — annually is a common practice. Each sending service should ideally use a separate DKIM selector to allow independent rotation. For Microsoft 365, DKIM is enabled per domain in the Microsoft Defender portal. For Google Workspace, DKIM is generated and published from the Admin console.

DMARC ALIGNMENT: Relaxed alignment (default) permits subdomain matches in SPF and DKIM. Strict alignment requires an exact match between the RFC5321.MailFrom or DKIM d= domain and the RFC5322.From domain. Relaxed alignment is appropriate for most business environments. Email forwarding frequently breaks SPF alignment but preserves DKIM alignment — this is one reason DKIM is important alongside SPF.

AGGREGATE REPORTS (rua): Published as a mailto: URI in the rua= tag. Reports are XML files compressed as gzip. Use a report processor (open-source options: parsedmarc, dmarc-visualiser; commercial: Dmarcian, Valimail, EasyDMARC) to make them readable. Reports arrive daily from major providers. Confirm your reporting address is a monitored mailbox or a reporting service.

FORENSIC REPORTS (ruf): Forensic reports contain redacted copies of individual failing messages. Many major providers no longer send them due to privacy concerns. They should not be relied upon as the primary monitoring mechanism. If used, treat the data carefully.

MICROSOFT 365: SPF is published in DNS and should include spf.protection.outlook.com. DKIM is enabled per domain from Microsoft Defender > Email & collaboration > Policies & rules > Threat policies > Email authentication settings. Microsoft’s Anti-spoof intelligence and Defender policies use DMARC results as signals. EOP honours DMARC reject policies for inbound external email by default.

GOOGLE WORKSPACE: SPF should include _spf.google.com. DKIM is enabled per domain from Admin console > Apps > Google Workspace > Gmail > Authenticate email. Google Postmaster Tools provides sender reputation and authentication monitoring for high-volume senders. Gmail enforces DMARC policies for inbound external email.

THIRD-PARTY SENDERS: Each service that sends email using your domain must be either included in SPF (add their include: or ip4:/ip6: mechanism) or configured to sign with DKIM using your domain (requires access to DNS to publish their public key). Both mechanisms should be present where possible. Marketing platforms, CRM systems, ticket systems, web hosting providers, accounting software, printers and scanners are common omissions.

POLICY PROGRESSION: Do not publish p=reject without at minimum several weeks of p=none monitoring followed by a period at p=quarantine. Confirm that aggregate reports show all legitimate senders passing authentication before tightening policy. Document the configuration state at each stage. Test by sending from each sending service and reviewing report data.

DNS PROPAGATION: DNS changes typically propagate within minutes to a few hours but can take up to 48 hours in edge cases. Verify records using MXToolbox, DMARC Analyser or equivalent after publication. Validate DMARC record syntax before assuming it is correct.