Tucango
Back to blog
Marketing & Web

How to Stop Email Spoofing of Your Domain: SPF, DKIM and DMARC Step by Step

· Tucango Team · 12 min read

Email key on a keyboard, a symbol of a company's email

A customer calls to ask about an "overdue invoice" they received from your email address. You never sent it. Someone used your company's name to trick them, and the worst part is that your domain had no way to stop it.

This is called domain spoofing, and you prevent it with three records configured in your domain's DNS: SPF, DKIM and DMARC. You don't need to be an engineer to understand them. In this guide we explain what each one does, how to check your domain in 10 minutes with free tools, and the safe path to full protection without your own emails getting blocked.

What Domain Spoofing Is and Why It Matters

Email was designed decades ago with no built-in way to verify who sends each message. That is why anyone can type billing@yourcompany.com in the "From" field of an email. The SPF standard acknowledges this upfront: any server can use whatever domain name it wants when sending an email (RFC 7208).

If your domain is not protected, you are exposed to three problems:

  • Phishing aimed at your customers and suppliers. Fake emails carrying your brand that ask for payments, data or passwords. Chile's Government CSIRT reports that the State Connectivity Network blocked more than 700,000 malicious emails in 2023, which is why it recommends implementing these three protocols (CSIRT, SPF, DKIM and DMARC manual, in Spanish).
  • Worse deliverability. Gmail warns that messages that are not authenticated may be marked as spam or rejected (Google, Email sender guidelines). In other words, your legitimate quotes and newsletters can end up in the spam folder.
  • Damage to your reputation. If your brand shows up in a scam, customers don't distinguish between "they spoofed me" and "this company can't be trusted."

SPF, DKIM and DMARC Explained Simply

Three verified envelopes and a shield with a padlock, representing an email protected with SPF, DKIM and DMARC

Think of your domain as a building with a front desk.

SPF: The List of Who Can Send on Your Behalf

SPF (Sender Policy Framework) is a TXT record in your DNS that lists the servers authorized to send email using your domain (RFC 7208). If you use Google Workspace plus a newsletter service, both need to be on that list. Google sums it up this way: your SPF record must include every email sender for your domain (Google).

It looks something like this: v=spf1 include:_spf.google.com ~all

DKIM: The Signature That Proves the Email Is Yours

DKIM (DomainKeys Identified Mail) adds a digital signature to every email you send. Your server signs with a private key, and you publish the public key in your DNS under a name like selector._domainkey.yourdomain.com (RFC 6376). That way, the recipient can verify that you sent the email and that nobody altered it along the way (Yahoo Sender Hub).

Gmail requires a key of at least 1,024 bits and recommends 2,048 bits if your DNS provider supports it (Google).

DMARC: The Rule That Says What to Do With Impostors

DMARC ties the other two together. It is a TXT record published at _dmarc.yourdomain.com that tells Gmail, Outlook and the rest what to do with emails that claim to come from your domain but fail SPF and DKIM: let them through (p=none), send them to spam (p=quarantine) or reject them (p=reject) (RFC 9989).

DMARC also requires alignment: passing SPF or DKIM is not enough; the authenticated domain has to match the one shown in the email's "From" field (Google). And with the rua tag you receive daily reports on everyone sending email with your domain, impostors included.

Latest update: in May 2026, DMARC became an official Internet standard with RFC 9989, which replaces the older RFC 7489. The essentials stay the same, but the pct tag (applying the policy to a percentage of messages) has been deprecated and replaced by t=y, a testing mode.

Step by Step: Check Your Domain in 10 Minutes

Person checking their company inbox on a laptop to verify SPF, DKIM and DMARC

You don't need technical access to run this check. All you need is your domain and these free tools.

1. Run the General Check With Google Admin Toolbox

Go to Google Admin Toolbox Check MX, enter your domain and review the alerts. It will tell you whether SPF, DKIM or DMARC is missing and whether there are configuration issues. Google recommends it for checking and fixing your domain setup (Google).

2. Look Up Each Record With Dig or MXToolbox

With Google Admin Toolbox Dig (choosing TXT) or MXToolbox, check:

  • SPF: look for a TXT record on your root domain that starts with v=spf1. There must be only one: two SPF records cause a permanent error (RFC 7208, section 4.5).
  • DKIM: look for the TXT record at selector._domainkey.yourdomain.com. If you use Google Workspace, the default selector is google, so the name is google._domainkey (Google, Set up DKIM).
  • DMARC: look for the TXT record at _dmarc.yourdomain.com. Check the value of p= and whether rua= exists. MXToolbox also has a DMARC checker.

3. Check a Real Email

Send yourself an email from your domain to a Gmail account, open the ⋮ menu and choose "Show original." There you'll see whether SPF, DKIM and DMARC say PASS. Repeat the test with every tool that sends email on your behalf: your CRM, your newsletter platform or your online store.

Common Mistakes (and How to Avoid Them)

Leaving DMARC at p=none Forever

p=none is a good starting point, because it lets you receive reports without affecting delivery. But the standard itself calls it "monitoring mode" and distinguishes it from real protection, which starts when the policy is no longer none (RFC 9989). If you've been on none for months, your domain is just as exposed as before.

Misreading SPF's ~all

~all (softfail) means a server is probably not authorized, and the standard says an email should not be rejected based on that result alone (RFC 7208, section 8.5). Note that Google recommends using ~all (Google, Set up SPF), so it is not a mistake in itself. The problem arises when ~all is paired with DMARC at none: nobody is asking receivers to block impostors. Real protection comes from DMARC at quarantine or reject.

Going Over 10 DNS Lookups in SPF

Every include, a, mx, ptr, exists or redirect uses one DNS lookup, and the limit is 10. If you exceed it, SPF returns a permanent error and stops working (RFC 7208, section 4.6.4). Keep in mind that each include can contain other includes. This happens a lot when tools keep getting added and nobody removes the ones no longer in use.

Publishing the DKIM Key in the Wrong Place

The key goes at selector._domainkey.yourdomain.com, not on the root domain or at _dmarc. A very common mistake is pasting the v=DKIM1; k=rsa; p=... value into the wrong name field in the DNS panel.

Forgetting Services That Send on Your Behalf

Mailchimp, Elastic Email, MailPoet, your CRM, your invoicing system or your website's server: each one must be authorized in SPF and, ideally, sign with DKIM using your domain. Microsoft explicitly asks this of third-party services: that they sign with DKIM using your domain and that your SPF includes their servers (Microsoft Support). Each provider gives you the exact values in its "domain authentication" panel.

The Safe Path: From p=none to reject

Chile's Government CSIRT recommends rolling out these protocols gradually so legitimate email is not disrupted (CSIRT). This is the path we recommend, based on Google's guide (Recommended DMARC rollout):

  1. Set up SPF and DKIM for all your senders. Google asks you to do this at least 48 hours before turning on DMARC.
  2. Publish DMARC in monitoring mode: v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. Review the reports for at least a week (Google notes this is usually enough to see all your email flows).
  3. Fix every legitimate sender that shows up as failing.
  4. Move to quarantine: p=quarantine. If you want to be cautious, you can add t=y while testing (RFC 9989).
  5. Get to reject: p=reject. Keep in mind that with reject, emails that fail DMARC are never delivered (Google).

Keep reviewing the reports afterward: every time you add a new tool, you'll need to authorize it.

What Gmail, Yahoo and Outlook Require

This is no longer just best practice. The major providers require it.

Gmail (since February 1, 2024) (Google):

  • All senders: SPF or DKIM, valid forward and reverse DNS, a TLS connection and a spam rate below 0.30% in Postmaster Tools (ideally below 0.10%).
  • If you send more than 5,000 emails a day to Gmail accounts: SPF, DKIM and DMARC (it can be p=none), alignment with the "From" domain and one-click unsubscribe in marketing emails, with a visible link in the body.

Yahoo (since February 2024) (Yahoo Sender Hub):

  • Bulk senders: SPF and DKIM, a valid DMARC record of at least p=none that passes, a spam rate below 0.3%, one-click unsubscribe and honoring unsubscribes within 2 days.

Outlook.com, Hotmail and Live (since May 5, 2025) (Microsoft Postmaster and Microsoft Support):

  • Domains sending 5,000 or more emails to Microsoft's consumer email services: passing SPF and DKIM, a published DMARC record (at least p=none) and alignment. Senders that don't comply get the 550 5.7.515 rejection.

If you send newsletters to your list, review this before your next campaign. And if WhatsApp is also part of your campaigns, see our guide to bulk WhatsApp messaging without getting blocked.

Extras Once You're Protected

  • BIMI: lets you show your brand logo next to your emails in supported providers. It requires DMARC at quarantine or reject; it does not work with p=none (Google, Set up BIMI).
  • MTA-STS: protects the emails you receive, because it requires them to arrive over an encrypted TLS connection (RFC 8461).

Frequently Asked Questions

What Is the Difference Between SPF, DKIM and DMARC?

SPF lists the servers that can send email with your domain. DKIM signs every email to prove it's yours and that it wasn't altered. DMARC tells receivers what to do with emails that fail those checks and sends you reports.

Is SPF Enough?

No. SPF alone does not protect the "From" address your customer sees. To prevent spoofing you need DMARC at quarantine or reject, backed by SPF and DKIM aligned with your domain.

Can Setting Up DMARC Stop My Emails From Being Delivered?

At p=none it does not affect delivery. The risk appears when you move to quarantine or reject without having authorized all your services. That's why it's best to move in stages and review the reports.

How Long Does a DNS Change Take to Apply?

It depends on each record's TTL and your DNS provider. That's why Google recommends setting up SPF and DKIM at least 48 hours before turning on DMARC.

I Send Fewer Than 5,000 Emails a Day. Does This Still Affect Me?

Yes. Gmail requires SPF or DKIM from all senders, and unauthenticated emails can go to spam or be rejected. On top of that, spoofing can hit any domain, whether it sends a little or a lot.

How Do I Know if Someone Is Spoofing My Domain?

Turn on DMARC with the rua tag. The daily reports show you which servers are sending email with your domain and whether they pass or fail authentication.

Want to Know if Your Domain Is Protected?

At Tucango we review your domain and your company's email setup: SPF, DKIM, DMARC and every tool that sends email on your behalf. We give you a clear diagnosis and support you all the way to p=reject without losing a single legitimate email.

  • Do you send newsletters or campaigns? We review it alongside your digital marketing strategy.
  • Are your website or email hosted with us? It's included in our hosting and support service.

👉 Get in touch and we'll review your domain.

Sources

Related articles

Available for new projects

Ready for your next big leap?

Let's talk, no strings attached. We'll show you how brands like yours are already growing with Tucango.

Get a proposalChat on WhatsApp