Phishing and Email Spoofing: DMARC, SPF and DKIM Explained

SPF, DKIM and DMARC are three DNS records that let any mail server check whether a message claiming to come from your domain really came from your company. SPF lists who may send on your behalf, DKIM signs each message, and DMARC tells the receiver what to do when a check fails and sends you reports. Set up together and taken to a reject policy, they stop attackers from using your exact domain to deceive your customers, suppliers and staff.

Why email spoofing is a business problem

Phishing still tops the list of reported internet crimes. In its 2025 report, the FBI’s Internet Crime Complaint Center (IC3) logged 191,561 phishing and spoofing complaints, the most reported category of the year. Business email compromise (BEC) accounted for 24,768 complaints and more than $3.04 billion in reported losses, the second costliest crime after investment fraud.

The same pattern shows up in confirmed breaches. Verizon’s 2026 DBIR found phishing was the way in for 16% of breaches in its global dataset, and for 20% of breaches in Latin America and the Caribbean, a regional sample of 718 confirmed breaches. These are not Panama-specific figures, but they describe the environment companies in Panama operate in.

For a business the typical scenario is very concrete: a message that seems to come from your CEO asks for an urgent payment, or an email from a supplier’s domain says their bank account has changed. If the attacker can put your exact domain in the From line, the scam is far more convincing to your team and to your customers. SPF, DKIM and DMARC exist to close that door.

SPF: the list of who may send for your domain

SPF (Sender Policy Framework) is a TXT record in your domain’s DNS that lists the servers and services allowed to send mail on your behalf. When a message arrives, the receiving server checks whether the sending IP address is on that list.

It has two limits worth knowing. First, SPF checks the envelope domain, the technical bounce address, and not necessarily the sender your user sees in Outlook. Second, the standard (RFC 7208) caps an SPF evaluation at 10 DNS lookups; if your record goes past that, the result is a permanent error and your messages stop passing the check.

That cap arrives sooner than people expect. Microsoft 365 or Google Workspace, the billing system, the CRM, the newsletter platform and the website contact form can each add their own entry. That is why an SPF record that worked two years ago may be failing today without anyone noticing. Each time you add or retire a sending service, the SPF record needs a review.

DKIM: the signature that proves a message was not altered

DKIM (DomainKeys Identified Mail) adds a cryptographic signature to every outgoing message. The public key is published in your DNS, and the receiver uses it to confirm two things: that a specific domain signed the message and that its content did not change in transit.

Unlike SPF, the DKIM signature travels inside the message, so it does not depend on the server that delivers it and usually survives forwarding. That makes it the most reliable piece for passing DMARC.

A detail many companies miss: Microsoft states that outbound mail from your custom domains in Microsoft 365 is not DKIM signed until you configure signing for each domain. The same applies to every outside service that sends for you, from invoicing to newsletters: each one needs its own DKIM setup with your domain.

DMARC: the rule that ties SPF and DKIM together

DMARC (Domain-based Message Authentication, Reporting and Conformance) is a TXT record published at _dmarc.yourdomain.com, and it does three jobs. The first is alignment: to pass DMARC, a message must pass SPF or DKIM with the same domain that appears in the visible From address. That closes the gap SPF leaves open on its own.

The second job is reporting. With the rua tag, mailbox providers send you aggregate reports showing which servers sent mail using your domain and whether it passed. With that data you know which legitimate services still need fixing and who is trying to impersonate you. Without reports, any change to your policy is a guess.

The third is deciding what happens to mail that fails. The policy has three levels:

• p=none: monitor only. Mail is delivered as usual and you receive the reports.
• p=quarantine: asks the receiver to treat failing mail as suspicious, usually by sending it to the spam folder.
• p=reject: asks the receiver to refuse failing mail. This is the level that actually stops others from spoofing your domain.

The new 2026 DMARC standard and what Gmail and Outlook require

In May 2026 the IETF published RFC 9989, which replaces RFC 7489, an earlier informational version, and makes DMARC a formal internet standard. Your existing records keep working, because the version is still v=DMARC1. The practical changes: the pct tag, used to apply a policy to only a percentage of mail, is gone; a new t tag signals that you are in test mode; and the np tag sets a policy for subdomains that do not exist.

The large mailbox providers already require it. Since February 1, 2024, Google has asked every sender to Gmail accounts to set up SPF or DKIM, and requires senders of more than 5,000 messages a day to have SPF, DKIM and a DMARC record, which may be set to p=none, with an aligned From domain. Microsoft announced equivalent rules for Outlook.com starting May 5, 2025: domains sending more than 5,000 emails a day must pass SPF and DKIM and publish DMARC with at least p=none. Non-compliant mail goes to the Junk folder first and may eventually be rejected.

Even if your company does not send 5,000 emails a day, your newsletters, statements or CRM can approach that volume on a campaign day. And the main reason to set this up is not deliverability: it is making sure nobody else can write in your name.

How to reach p=reject without blocking your own mail

The classic mistake is publishing p=reject on day one and finding out that invoices or newsletters stopped arriving. The safe path goes in stages, guided by the reports, as Microsoft’s own guidance recommends:

1. Inventory. List every service that sends with your domain: Microsoft 365 or Google Workspace, invoicing, CRM, newsletter platforms, website forms, even the multifunction printers that email scans.

2. DMARC in monitoring mode. Publish p=none with rua reporting and let it run for several weeks, so that mail sent only at month end shows up too.

3. Fix SPF and turn on DKIM. Add each legitimate service to SPF without going past 10 lookups, and enable DKIM on each one, aligned with your domain.

4. Quarantine. When the reports show your legitimate mail passing, move to p=quarantine and watch the results.

5. Reject. Once quarantine is stable, move to p=reject. Also publish p=reject on domains your company owns but does not use for email: a domain without DMARC can be used to impersonate you even if you never send from it.

At Techno we run this process with Cloudflare DMARC Management, which shows every service sending on behalf of your domain and whether it passes; it is available for domains that use Cloudflare DNS. Our Cloudflare team tightens the policy in stages and makes each decision from the reports, not blindly.

What DMARC does not solve

DMARC protects your exact domain. It does not stop someone from registering a lookalike domain with one letter changed, or from using a free email account with your CEO’s name as the sender. Nor does it stop a message sent from a supplier’s real mailbox after their password was stolen: that message passes SPF, DKIM and DMARC because it is genuine.

That is why DMARC is one layer of a business cybersecurity strategy, and it needs other layers around it. These are the ones we recommend:

• Inbound email filtering that catches phishing, lookalike domains and supplier fraud, with Defender for Office 365 or Cloudflare Email Security, depending on your license and your level of risk.
• MFA for everyone, phishing-resistant where possible, so a stolen password does not open a mailbox. We cover it in our guide to Microsoft 365 security.
• A payment process: any bank account change or urgent payment is confirmed through a channel other than email, with a contact you already know.
• Short, frequent training so your team recognizes the signs of a fraudulent email before clicking.

Frequently asked questions

Does my company need DMARC even if it is small?

Yes. Spoofing does not depend on size: all it takes is a domain that your customers trust. Gmail and Outlook also already require SPF, DKIM and DMARC from anyone sending large volumes of email.

Can moving DMARC to p=reject block my own mail?

Yes, if it is done without reviewing the reports. That is why you start at p=none, fix SPF and DKIM on every legitimate service, and only then move to quarantine and reject.

Does DMARC stop all phishing?

No. It stops the use of your exact domain. Lookalike domains, free accounts with fake names and compromised third-party mailboxes call for email filtering, MFA and a payment verification process.

What changed with RFC 9989?

Since May 2026 DMARC is a formal IETF standard. Your v=DMARC1 records keep working; the pct tag is retired and replaced by the t tag for test mode, and the np tag sets the policy for subdomains that do not exist.

What should I do with domains I do not use for email?

Publish an SPF record that authorizes no servers (v=spf1 -all) and a DMARC record with p=reject. That way nobody can send convincing mail from those domains.

If you want to know where your domain's SPF, DKIM and DMARC stand today, send us your domain and we will tell you what to fix first. Protect your domain's email

Sources

1. FBI IC3 – 2025 Internet Crime Report (2026): Phishing and spoofing with 191,561 complaints, the most reported category; BEC with 24,768 complaints and $3,046,598,558 in reported losses, second by losses.
2. Verizon – 2026 Data Breach Investigations Report: Phishing as the initial access vector in 16% of breaches; 20% of 718 confirmed breaches in Latin America and the Caribbean.
3. Google – Email sender guidelines (Gmail Help): Since February 1, 2024: SPF or DKIM for all senders; SPF, DKIM, DMARC (may be p=none) and alignment above 5,000 messages a day.
4. Microsoft Community Hub – Strengthening Email Ecosystem: Outlook's New Requirements for High-Volume Senders (2025): From May 5, 2025, SPF, DKIM and DMARC of at least p=none for domains sending more than 5,000 emails a day to Outlook.com; non-compliant mail goes to Junk and may be rejected.
5. IETF – RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance (DMARC) (2026): May 2026 standard that obsoletes RFC 7489 and RFC 9091; removes the pct tag and adds the t and np tags.
6. IETF – RFC 7208: Sender Policy Framework (SPF) (2014): Limit of 10 DNS lookups per SPF evaluation; exceeding it returns a permanent error.
7. Microsoft Learn – How to use DKIM for email in your custom domain: Outbound mail from custom domains is not DKIM signed until signing is configured for each domain.
8. Microsoft Learn – Set up DMARC to validate email in Microsoft 365: Staged rollout: p=none to monitor, then p=quarantine and p=reject, reviewing the reports.
9. Cloudflare Docs – DMARC Management: DMARC reports per sending service; available to customers using Cloudflare DNS.