Can someone send email as your business? What SPF, DKIM and DMARC decide

Yes. DMARC is a record on your domain that can tell other mail servers what to do with mail that forges your address. Set to quarantine or reject, it asks them to junk or refuse that mail. Without it, they have nothing from you to act on. Receivers do not have to follow it. And no DMARC setting stops lookalike domains, or mail sent from a mailbox somebody has broken into. Those are covered at the end.

Email was not built to check who sent a message. Microsoft's documentation says that SMTP, the protocol mail travels on, makes no effort to check that the sender is who they claim to be. Its worked example is a message whose From line shows a bank's address, while the hidden sender address it travels under (the envelope) carries an unrelated domain.

Three records in your domain's settings (its DNS) decide whether a receiving mail server can tell your mail from a forgery: SPF, DKIM and DMARC. Only DMARC tells the receiver what you want done with a forgery, and only a policy of quarantine or reject asks it to do anything.

None of the laws read for this guide names any of the three. GDPR Article 32 requires security of personal data appropriate to the risk and names no email control. Ireland's National Cyber Security Centre (NCSC) recommends all three records. Gmail, Yahoo and Outlook.com require them from bulk senders before they will deliver to their users. The one legal text read that deals with email security directly covers cloud, DNS and managed service providers under NIS2. It is described below.

Your DMARC protects anybody whose mail system acts on it: the customer who receives an invoice that appears to come from you, and your own staff when a forgery of your managing director's address arrives from outside and your own mail system honours the policy.

Each answers a different question. A forged message can pass the first two.

The missing piece is called alignment. SPF checks the envelope sender, an address used between mail servers that the reader never sees. DKIM checks whichever domain signed the message. Neither has to match the From address the reader sees. Microsoft's documentation describes the forgery this allows: register a domain, set up SPF and DKIM for it, and send mail with somebody else's domain in the From line. Both checks pass, for the wrong domain.

DMARC closes the gap. A message passes DMARC only where SPF or DKIM passed for a domain aligned with the From address. Aligned means the same domain or, under the default relaxed setting, one with the same main domain (organisational domain). That is how invoices.yourdomain.ie aligns with yourdomain.ie. A message passes if either check passes aligned, and fails only if both fail. DMARC also lets the domain owner say what should happen to a message that fails, and ask receivers for reports.

The DMARC standard itself changed this year. It was first published as RFC 7489, an informational document. In May 2026 the Internet Engineering Task Force replaced it with RFC 9989, a formal standard (standards track), with aggregate reports defined in RFC 9990 and failure reports in RFC 9991. The tags at the core of a record (v=DMARC1, p, sp, rua, adkim and aspf) are all still in it. Three changes affect a small business, and they are in the table of tags below. The pct tag is gone. A test flag, t, replaces part of what it did. And an np tag, for subdomains that do not exist, is now part of the standard; it was first defined in an experimental RFC of 2021.

The p tag is the policy, and it has three values. RFC 9989 defines them by what the domain owner tells receivers about mail that fails: none means the owner states no preference; quarantine means the owner considers such mail suspicious; reject means the owner considers the failure a clear indication that use of the domain is not valid.

What a receiver then does is its own decision, and RFC 9989 says it can choose to honour the policy but is not required to. Microsoft documents what Microsoft 365 does with incoming mail when its setting to honour the sender's DMARC policy is on. At p=none, it takes no DMARC-specific action, and other filtering still applies. At p=quarantine, the message goes to the Junk Email folder. At p=reject, it is refused during delivery.

At p=none a forged message carrying your address gets no DMARC treatment and is judged on whatever other filtering the receiver runs. The point of p=none is the reports. RFC 9989 calls it monitoring mode: the policy is none, and the domain owner receives summary reports (aggregate reports) and uses them to fix its own mail before asking receivers to act.

A p=none record with no report address (rua) gets no reports either: RFC 9989 says receivers must not send aggregate reports when the rua tag is absent. That record asks for nothing and receives nothing. A record with no valid p tag is treated as p=none if it names a rua address, and ignored altogether if it does not.

A DMARC record is one line of tags separated by semicolons, published as a TXT record at _dmarc in front of your domain name. Publish exactly one: Microsoft's DMARC guide says to make sure only one _dmarc TXT record exists.

Microsoft's and Google's setup guides both still suggest pct for a gradual move, starting with a small percentage of failing mail and raising it. RFC 9989 removed pct, because experience showed it was usually not applied accurately unless the value was 0 or 100. The new standard also says unknown tags must be ignored. Make the move in whole policy steps, from none to quarantine and, if you go on, to reject.

Google's sender guidelines have applied since 1 February 2024 to anybody sending to personal Gmail accounts. Every sender has to set up SPF or DKIM. A sender of 5,000 or more messages a day to Gmail accounts needs all three: SPF, DKIM and DMARC. Its From domain must be aligned with SPF or DKIM, and marketing mail needs one-click unsubscribe. Google says the DMARC policy can be set to none. Unauthenticated messages might be marked as spam or rejected.

Google counts messages from the same primary domain together, subdomains included. A sender that meets the bulk criteria once is treated as a bulk sender permanently. A business sending well under 5,000 messages a day to personal Gmail accounts is not a bulk sender. Only the requirements for all senders apply to it, and the authentication requirement among them is SPF or DKIM, not DMARC. Google's guidelines do not apply to mail sent to Google Workspace accounts at all. Since November 2025 Gmail has been enforcing the requirements more strictly. Messages that fail them can run into problems, including being rejected temporarily or permanently.

Yahoo set rules of the same shape from February 2024: SPF or DKIM for every sender, and for bulk senders SPF and DKIM both, a DMARC policy of at least p=none that passes, alignment, and one-click unsubscribe. Yahoo's page gives no volume figure for bulk.

Microsoft announced on 2 April 2025 that, from 5 May 2025, domains sending more than 5,000 messages a day to Outlook.com consumer addresses (outlook.com, hotmail.com and live.com) must pass SPF and DKIM and publish DMARC at p=none or stronger, aligned with SPF or DKIM. The announcement's update says failing messages are rejected with the error 550 5.7.515. A paragraph lower down in the same post still says they go to Junk first.

These are the providers' conditions for reaching their own users. All three accept p=none, which means meeting them does not, on its own, ask anybody to stop a forgery.

In Ireland, the NCSC has guidance on business email compromise and payment fraud, dated 25 July 2025. It tells organisations to set up and monitor SPF, DKIM and DMARC on their domains. It gives them as a defence at the stage of an attack where criminals pretend to be somebody trusted, using broken-into accounts, forged (spoofed) addresses or lookalike domains they have registered. It links this control to the CyberFundamentals framework, which it recommends (control PR.PT-4). Its Irish examples include a local authority that paid over €500,000 in 2023 on a fake invoice from a forged supplier email address, and it puts SME losses to invoice redirect fraud in 2023 at almost €10m. The payment side is in the invoice redirection guide, and the framework in CyFun, ISO 27001 and Cyber Essentials compared.

One legal text deals with email security directly, but only for a narrow group. Commission Implementing Regulation (EU) 2024/2690 sets out the detail of NIS2's security measures for DNS service providers, cloud computing and data centre providers, managed and managed security service providers, and the other digital providers its Article 1 lists. Among those measures it requires a plan for deploying internationally agreed and interoperable modern email communications standards, without naming any. NIS2 in Ireland covers where Irish transposition stands, and the NIS2 supplier guide covers what a customer in scope asks of its suppliers.

On 2 October 2026 FourWinds looked up the DMARC records of 400 Irish small-business email domains on its own outreach list: 61% had no DMARC record, 32% had DMARC at p=none, and 7% enforced it, at p=quarantine or p=reject. It is the list of businesses FourWinds was writing to, not a national sample.

A published count of large companies reads differently. On 22 July 2026 Red Sift, an email security company, published the DMARC policies of 201 of Ireland's largest companies. Of the 101 founded in Ireland, 39.6% were at p=reject, 33.7% at p=quarantine, 16.8% at p=none and 9.9% had no record. Of the 100 multinationals with major operations in Ireland, 63% were at p=reject, 20% at p=quarantine, 13% at p=none and 4% had no record. Red Sift does not say how the companies were chosen or when the records were read.

The two counts cover different businesses, measured by different people, and neither is a national figure.

Three lookups answer most of the question, and an online DMARC checker or SPF checker runs the same ones. From a command prompt, with your own domain in place of yourdomain.ie:

For a domain whose only sender is Microsoft 365, Microsoft gives the record as v=spf1 include:spf.protection.outlook.com -all. For Google Workspace, Google gives v=spf1 include:_spf.google.com ~all. Every other service that sends with your domain in its envelope adds its own include or IP address to the same record, because the domain can have only one.

The ending is the instruction for anything not listed. A -all says the source is not authorised; a ~all says it probably is not. Google recommends ~all. Microsoft recommends -all, and says why: DMARC treats both endings as SPF failures, but a DMARC policy is effectively ignored for ~all failures when the message carries no DKIM signature.

The record has a limit that a business adding services will run into. RFC 7208 allows ten DNS lookups while a receiver evaluates it: include, a, mx, ptr, exists and redirect each count, and ip4, ip6 and all do not. An include can contain further includes and those count too, so fewer than ten includes does not guarantee fewer than ten lookups. Past the limit the result is permerror, an SPF failure, for any message whose check runs beyond the tenth lookup.

Microsoft gives three ways to get back under the limit: replace a service's include with its published IP addresses where they are stable, move a service onto a subdomain with its own SPF record (each subdomain has its own limit), or send through fewer services. Microsoft says not to replace its own include with addresses, because its sending addresses change.

A DKIM key is published at a name made of a selector and _domainkey. A receiver learns the selector from the signature on each message (its s= value). An outside check with no message to read has to guess the selector. Finding nothing at the names it tried does not show that there is no key.

You can confirm your own key. Microsoft 365 uses two selectors, selector1 and selector2, published as CNAME records; Google Workspace's default selector is google, published as a TXT record. nslookup -type=CNAME selector1._domainkey.yourdomain.ie, or nslookup -type=TXT google._domainkey.yourdomain.ie, shows whether the key is published.

The message itself is the better test. Send one to a mailbox on another service and open its headers. The Authentication-Results line shows the spf=, dkim= and dmarc= results, smtp.mailfrom= shows the envelope domain SPF was checked against, and header.d= shows which domain signed it. If neither of those two domains is yours, or a subdomain of yours, the message is not aligned and fails DMARC.

Keep a copy of what the lookups and a message header showed, with the date. If a customer's or an insurer's security questionnaire asks about email authentication, that is the evidence, and the cyber insurance questionnaire guide covers the rest of the form.

Once rua is set, receivers that send reports send each one as a data file (XML), which RFC 9990 says should be compressed. RFC 9989 asks receivers to send them at least once every 24 hours. It also says receivers do not have to send them at all. The reports go to whatever address rua names, so make it a mailbox kept for the purpose: Microsoft advises against a person's own inbox.

Each row covers one sending IP address: how many messages it sent with your domain in the From line, what the receiver did with them, and whether DKIM and SPF passed and whether they aligned. Passing and aligning are different results, and the gap between them is where the work is. Microsoft's guide to reading the reports gives these patterns.

Moving to enforcement before every legitimate sender passes gets your own mail junked or refused. Microsoft's guide says the reason for a gradual move is to stop receivers rejecting good mail because of unintentional DMARC failures, and its Outlook.com announcement advises the same order: none, then quarantine, then reject. Even done slowly, Microsoft's guide expects some genuine mail to be wrongly flagged (false positives), which is one reason the reports stay on.

RFC 9989 says it may take many months of reading aggregate reports, depending on how often each kind of mail is sent, before a domain owner is sure all its mail authenticates.

Microsoft's guide sets p=reject as the goal for all your domains and subdomains. RFC 9989, the standard itself, is more cautious about that last step. Either policy keeps a forgery of your exact domain out of the inbox at receivers that honour it: quarantine asks for the message to be treated as suspicious, which at Microsoft 365 means the Junk Email folder, and reject asks for it to be refused.

RFC 9989 says domains used for general-purpose email should not publish p=reject, and in particular that a domain whose users might post to mailing lists should not. A list sends each post on from its own servers, which breaks SPF. If it also changes the message, DKIM breaks too, and the post fails DMARC at the subscribers' mail systems. If a subscriber's system refuses the post, the list software can treat that address as dead and unsubscribe it automatically. The RFC also records that mailing list software has adopted workarounds that rewrite the From line, and that list mail without one is still frequently refused.

A domain that goes to p=reject anyway should, under RFC 9989, first publish p=none for at least a month and then p=quarantine for as long again, comparing what happened to its mail under each. It must sign its mail with DKIM and not rely on SPF alone, because forwarding breaks SPF and a DKIM signature generally survives it.

The standard also tells receivers not to reject a message on p=reject alone: they are to weigh the policy with other evidence and, if there is none, treat the message as if the policy were quarantine. RFC 9989's conditions for the last step turn on two facts about the business: whether DKIM signs every message it sends, and whether anybody might post to mailing lists from the domain.

RFC 9989 is explicit about its own limits. DMARC acts directly only on forgery of your exact domain (exact-domain spoofing). It does not deal with domain names that look similar, or with misuse of the display name.

A lookalike domain is somebody else's domain, with its own records, controlled by whoever registered it. Your DMARC policy has nothing to say about it. The NCSC lists registered lookalike domains among the ways attackers impersonate trusted contacts, and advises watching for lookalike and typo registrations and blocking inbound mail from newly registered domains or domains with small typos.

A display name is the name shown beside the address. A message can carry a familiar person, brand or role as its display name over an address at any domain, and RFC 9989 puts that outside DMARC's scope.

A mailbox somebody has broken into is the hardest case. Mail sent from your own mailbox by somebody who has its password comes from your real system and passes SPF, DKIM and DMARC like the rest of your mail, because a DMARC pass means only that use of the domain was authorised. The NCSC's answers are multi-factor authentication on all email accounts, checking for suspicious forwarding rules, and a call-back on any change of bank details, which is where the invoice redirection guide picks up.

Your DMARC protects anybody whose mail system acts on it: your customers and suppliers, and your own staff when a forgery of your managing director's address arrives from outside. CEO fraud, an attacker pretending to be a company executive, is the first business email compromise scenario the NCSC lists. Whether a forgery of a supplier's address reaches you depends on the supplier's DMARC and on your own mail system. In Microsoft 365, the anti-phishing policy setting "Honor DMARC record policy when the message is detected as spoof" decides whether a sender's quarantine or reject is acted on.