Skip to main content
Secure Business Email

The attack arrives by email

Protect your business email from phishing, compromise and disruption.

Email is a common starting point for attacks on small businesses. SPF, DKIM and DMARC decide which mail claiming to be from your domain gets trusted, and many domains are not set up to stop impersonation.

Take the readiness assessment How this site can help

  • 01 Illustrations use reserved example domains only
  • 02 Nothing on this site checks your domain
  • 03 No password, MFA code or token is ever requested
Illustration, not a check of your domain
Email trust architecture: three sample messages pass through SPF, DKIM and DMARC checks to a policy outcome Three sample messages travel down from a sending domain through a receiving server, which checks SPF, then DKIM, then DMARC. Sample 1 passes with aligned SPF and DKIM and is delivered. Sample 2 passes SPF for a different domain, so it is not aligned with the From domain, has no DKIM signature, fails DMARC and is quarantined under p=quarantine. Sample 3 fails SPF, has no signature, fails DMARC and is rejected under p=reject. All domains are reserved example domains. SENDING DOMAIN · THREE SAMPLE MESSAGES 1 · LEGITIMATE billing@example.com envelope example.comsigned, d=example.com pending passexample.com pending passd=example.com pending passSPF+DKIM aligned Pendingawaiting DMARC resultno policy applied yet DeliveredDMARC passedaligned SPF or DKIMnormal filtering 2 · SPOOFED ceo@example.org envelope bounce.example.netunsigned pending passbounce.example.net pending noneno signature pending failSPF not aligned Pendingawaiting DMARC resultno policy applied yet QuarantinedDMARC failedpolicy p=quarantinejunk or quarantine 3 · SPOOFED ceo@example.com envelope example.comforged, unsigned pending failserver not listed pending noneno signature pending failno aligned pass Pendingawaiting DMARC resultno policy applied yet RejectedDMARC failedpolicy p=rejecttypically refused RECEIVING SERVERPOLICY OUTCOME SPFis the sending server allowed? DKIMdoes the signature verify? DMARCaligned SPF or DKIM pass? if not, apply policy Email trust architecture: three sample messages evaluated by a receiving server Three sample messages each pass through SPF, DKIM and DMARC checks. Sample 1 is delivered. Sample 2 passes SPF for another domain so is not aligned, fails DMARC and is quarantined under p=quarantine. Sample 3 fails SPF and DMARC and is rejected under p=reject. All domains are reserved example domains. SAMPLE 1 · LEGITIMATE billing@example.com envelope example.com, signed, d=example.com SPF pending passexample.com DKIM pending passd=example.com DMARC pending passboth aligned Pendingawaiting DMARC result Deliveredaligned pass SAMPLE 2 · SPOOFED ceo@example.org envelope bounce.example.net, unsigned SPF pending passother domain DKIM pending noneno signature DMARC pending failnot aligned Pendingawaiting DMARC result Quarantinedp=quarantine SAMPLE 3 · SPOOFED ceo@example.com envelope example.com, forged, unsigned SPF pending failnot authorised DKIM pending noneno signature DMARC pending failnone aligned Pendingawaiting DMARC result Rejectedp=reject
Three sample messages, using reserved example domains. DMARC passes only when SPF or DKIM passes and that passing domain aligns with the visible From domain. Sample 2 passes SPF, but for a different domain, so it still fails DMARC. Each domain publishes its own policy. A policy acts only on a failure: p=none observes, p=quarantine holds, p=reject refuses.

What receivers read

Three records decide what your domain is trusted for

Receiving mail systems look at DNS, not at your letterhead. These examples use the reserved name example.com and are shown only to explain the shape of each record. They are not a check of your domain and not a configuration to copy.

Always read your real records with your own DNS tools and your DNS provider’s console. Nothing on this site can see them. The SPF, DKIM and DMARC guide walks through each in order.

SPFTXT · ENVELOPE SENDER

example.com TXT “v=spf1 include:spf.protection.outlook.com -all“

Which servers may send mail using the domain in the envelope sender. One record per name, and a hard limit of 10 DNS lookups while it is checked.

DKIMTXT · SIGNATURE

selector1._domainkey.example.com TXT “v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A…”

The public key a receiver uses to check the signature on a message. The private key stays with the sending service. Each sender needs its own selector.

DMARCTXT · POLICY

_dmarc.example.com TXT “v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com”

What to do when neither SPF nor DKIM passes in alignment with the From domain, and where to send aggregate reports. p=none only observes; it blocks nothing.

Alignment and policy

A pass only counts if it matches the address people see

DMARC passes only if SPF or DKIM passes and the domain that passed aligns with the visible From domain. When it fails, the From domain’s published policy decides what happens next.

How DMARC combines SPF and DKIM with alignment to reach a policy outcome Five illustrative scenarios cycle. A message carries three domains: the visible From domain, the envelope sender checked by SPF, and the DKIM signing domain. SPF and DKIM each give a result, and a result only counts if its domain aligns with the From domain. DMARC passes if at least one aligned check passes. If DMARC fails, the From domain policy decides: p=none observes only, p=quarantine holds the message, p=reject refuses it. All domains are reserved example domains. ENVELOPE SENDER HEADER FROM (VISIBLE) DKIM SIGNING DOMAIN (d=) SPF CHECK DKIM CHECK ALIGNED WITH FROM? ALIGNED WITH FROM? DMARCevaluating DMARC passnormal filtering applies p=noneobserve and report only p=quarantinejunk or quarantine p=rejectrefused at delivery POLICY OF FROM DOMAIN Used only when DMARC fails. mail.example.comexample.comexample.compasspassalignedalignedpassScenario 1 of 5 · Authorised sender bounce.example.netexample.comnonepassnonenot alignedno resultfailScenario 2 of 5 · SPF passes, but does not align relay.example.netexample.comexample.comfailpassno resultalignedpassScenario 3 of 5 · Relayed: SPF fails, DKIM aligns example.orgexample.orgnonefailnoneno resultno resultfailScenario 4 of 5 · Fails under p=none example.comexample.comnonefailnoneno resultno resultfailScenario 5 of 5 · Fails under p=reject How DMARC combines SPF and DKIM with alignment to reach a policy outcome Five illustrative scenarios cycle. A message carries three domains: the visible From domain, the envelope sender checked by SPF, and the DKIM signing domain. SPF and DKIM each give a result, and a result only counts if its domain aligns with the From domain. DMARC passes if at least one aligned check passes. If DMARC fails, the From domain policy decides: p=none observes only, p=quarantine holds the message, p=reject refuses it. All domains are reserved example domains. HEADER FROM (VISIBLE) ENVELOPE SENDER DKIM d= DOMAIN SPF CHECK DKIM CHECK SPF ALIGNED? DKIM ALIGNED? DMARC: ANY ALIGNED PASSevaluating POLICY: USED ONLY ON DMARC FAIL DMARC passnormal filtering applies p=noneobserve and report only p=quarantinejunk or quarantine p=rejectrefused at delivery example.commail.example.comexample.compasspassalignedalignedpassScenario 1 of 5Authorised sender example.combounce.example.netnonepassnonenot alignedno resultfailScenario 2 of 5SPF passes, but does not align example.comrelay.example.netexample.comfailpassno resultalignedpassScenario 3 of 5Relayed: SPF fails, DKIM aligns example.orgexample.orgnonefailnoneno resultno resultfailScenario 4 of 5Fails under p=none example.comexample.comnonefailnoneno resultno resultfailScenario 5 of 5Fails under p=reject
Five illustrative scenarios, using reserved example domains. Not a check of any real domain. Alignment is shown in its default relaxed form, where the organisational domain must match. Each domain publishes its own DMARC policy, and it is looked up for the From domain.
  1. Authorised senderSPF and DKIM both pass and both align with the From domain. DMARC passes. A policy is only consulted when DMARC fails.
  2. SPF passes, but does not alignSPF passed for bounce.example.net, which is not the From domain, so it does not count. There is no DKIM signature. DMARC fails and p=quarantine applies.
  3. Relayed: SPF fails, DKIM alignsOne aligned pass is enough. SPF failed after relaying, but a valid DKIM signature from example.com aligns with From, so DMARC passes.
  4. Fails under p=noneNeither check passes in alignment, so DMARC fails. Under p=none the receiver only observes and reports; it does not act on the failure.
  5. Fails under p=rejectNeither check passes in alignment, so DMARC fails. Under p=reject the receiver refuses the message.

p=none

Observe. Failures are reported to you; mail is not blocked by DMARC.

p=quarantine

Act on failure by treating the message as suspect, typically junk or quarantine.

p=reject

Act on failure by refusing the message at delivery.

The safe order

The order matters more than any single setting

Most outages caused by email authentication come from enforcing a policy before every legitimate sender is accounted for. This is the sequence that avoids that.

p=none

Observe

p=quarantine

Hold failures

p=reject

Refuse failures

Steps 4 and 5 move through these policies only when the reports justify it.

  1. List every system that sends as your domain

    Mailboxes, invoicing, CRM, marketing, helpdesk, scanners, website forms. Anything missed here is what breaks later.

  2. Publish one accurate SPF record

    Merge, never duplicate, and stay inside the 10-lookup limit. How SPF is checked.

  3. Enable DKIM signing for each sender

    Use 2048-bit keys where the sender supports them, and keep a record of which selector belongs to whom.

  4. Publish DMARC at p=none, with reports

    Collect aggregate data for long enough to see the real mail flow, including the quiet monthly senders.

  5. Fix, then tighten to quarantine, then reject

    Move only when the reports show your legitimate mail aligning. Stage it, and keep a way back.

  6. Lock down domains that never send

    A parked domain should say so in DNS. Attackers prefer domains with no policy.

The guides

Where to start, by the problem in front of you

Seven guides, each written for an administrator or owner who has to make a decision this week.

Readiness assessment

See what to look at before you change anything.

Answer questions about your own setup, from what you can see in your admin consoles and DNS. The tool turns your answers into a prioritised list, in your browser. Nothing you enter is sent, and nothing is scanned.

Take the readiness assessment How this site can help

What this site will never do

  • Ask for a mailbox password, an MFA code, a token, a session cookie or the content of any message.
  • Scan, probe or look up your domain. The assessment only interprets answers you give it, in your browser.
  • Tell you a domain is protected, verified or correct. Only your own DNS tools and tenant settings can show that.
  • Imply any partnership with Microsoft, Google or another vendor.