Add to Preferred Sources
An email domain authentication checklist is a step-by-step guide for configuring the three DNS records — SPF, DKIM, and DMARC — that prove to Gmail, Microsoft, and Yahoo that your domain is the legitimate source of every message you send. Without these records, your campaigns land in spam regardless of how well the creative is written. If you're investing in email marketing in South Africa, domain authentication is the infrastructure those campaigns run on.
Since February 2024, Google and Yahoo have required authentication for bulk senders, and Microsoft followed with its own enforcement starting May 2025. Gmail escalated further in November 2025, with non-compliant senders now facing active rejections — not just delays. The ECT Act's Section 45 has always required a working unsubscribe mechanism; POPIA requires a lawful basis for direct marketing — consent being the most common — and mandates the right to opt out. Taken together, getting authentication right is both a deliverability requirement and a South African email compliance baseline.
Quick Answer
An email domain authentication checklist covers four layers: (1) an SPF TXT record listing every server authorised to send on your behalf, (2) a DKIM TXT record publishing your cryptographic signing key, (3) a DMARC TXT record telling inbox providers what to do with unauthenticated mail, and (4) optionally, a BIMI record displaying your logo once the first three are enforced. Start with SPF, stack DKIM, monitor with DMARC at p=none, then escalate policy to p=reject once your reports are clean. South African senders must also meet POPIA consent requirements and the ECT Act's unsubscribe obligation to stay legally compliant.
Jump to Section
Is Your Domain Authentication Blocking Your Campaigns?
Send us your domain and we will run a full SPF, DKIM, and DMARC check — and show you exactly which records are missing or misconfigured before your next send.
Get a Free Authentication CheckWhat Does an Email Domain Authentication Checklist Cover?
Email domain authentication is a set of DNS-based protocols that verify your domain is the genuine source of a message, not a spoofed or impersonated sender. Inbox providers check these records automatically; a message that fails authentication is either junked or rejected before your subscriber sees it.
Three protocols make up the foundation. Each solves a different part of the trust problem:
| Protocol | What It Does | DNS Record Type | Where It Lives |
|---|---|---|---|
| SPF | Lists every IP address and service authorised to send mail for your domain | TXT | @ (root domain) |
| DKIM | Attaches a cryptographic signature that proves the message content was not altered in transit | TXT | selector._domainkey |
| DMARC | Instructs inbox providers what to do if SPF or DKIM fail, and sends you reports on who is sending from your domain | TXT | _dmarc |
The gap between having these records and having them configured correctly is where most South African businesses lose campaigns. Globally, 70.9% of domains have no effective DMARC protection — either no record at all, or a monitoring-only policy that takes no enforcement action. Only 10.7% of domains have reached full protection with a strict reject policy at 100% enforcement.
Step 1: SPF Record Checklist
SPF (Sender Policy Framework) tells receiving mail servers which IP addresses and third-party services are allowed to send email on behalf of your domain. A single TXT record on your root domain is all that is required — but it must be accurate and within technical limits.
SPF Record Format
v=spf1 include:_spf.google.com include:servers.mcsv.net ~all
Replace the include: values with the identifiers from each service you use to send email (your ESP, CRM, transactional provider). End with ~all when DMARC is in place — DMARC handles enforcement, so a soft fail (~all) avoids over-blocking legitimate mail.
| SPF Checklist Item | Status |
|---|---|
| Identify every service that sends email from your domain (newsletter platform, CRM, transactional system, Google Workspace or Microsoft 365) | ☐ Done |
| Collect the SPF include value from each provider's documentation | ☐ Done |
| Check for an existing SPF record — there must be exactly one (duplicates cause authentication failure) | ☐ Done |
Confirm total DNS lookups are 10 or fewer (each include: counts as one lookup; exceeding the limit invalidates the entire record) | ☐ Done |
Create the TXT record at @ (root domain) with all includes and a ~all qualifier | ☐ Done |
| Verify the record has propagated (up to 48 hours) using MXToolbox or Google Workspace Toolbox | ☐ Done |
Common mistake: Creating two separate SPF TXT records because your host auto-generated one and your ESP gave you a different one. Two SPF records on the same domain cause authentication failure — merge them into a single record.
Step 2: DKIM Record Checklist
DKIM (DomainKeys Identified Mail) adds a cryptographic signature to the headers of every outgoing message. The receiving server verifies the signature against a public key you publish in DNS — if the signature matches, the message content is confirmed unaltered.
Most email service providers — Google Workspace, Microsoft 365, Klaviyo, Omnisend, Everlytic — generate the DKIM key pair for you. Your job is to publish the public key they supply into your DNS and confirm the selector matches.
DKIM Record Format
Host/Name: selector._domainkey.yourdomain.com
Value: v=DKIM1; k=rsa; p=[public key string]
The selector name (e.g., "google", "mail", "k1") comes from your email provider. Use 2048-bit RSA keys — 1024-bit is considered cryptographically weak and is being phased out by major inbox providers.
| DKIM Checklist Item | Status |
|---|---|
| Log into your email provider's admin panel and navigate to the DKIM or authentication settings | ☐ Done |
| Generate or locate the DKIM key pair (the provider retains the private key; you publish only the public key) | ☐ Done |
| Confirm the key length is 2048-bit (not 1024-bit) | ☐ Done |
| Note the selector name exactly — case-sensitive, must match what the provider expects | ☐ Done |
Create a TXT record in DNS: Host = selector._domainkey, Value = the full public key string starting with v=DKIM1; k=rsa; p= | ☐ Done |
| Enable DKIM signing in the provider's dashboard (publishing the DNS record alone is not enough) | ☐ Done |
| Repeat for each additional sending service (your newsletter platform and transactional provider need separate DKIM keys) | ☐ Done |
| Verify by sending a test message and checking authentication headers (Gmail: three-dot menu → "Show original" → look for DKIM: PASS) | ☐ Done |
Key Point: DKIM Alignment
For DMARC to pass on the DKIM path, the domain in the DKIM signature must match your visible "From" address domain. If you send from yourname@yourbusiness.co.za but your DKIM is signed under a third-party domain (common with white-label ESPs), alignment will fail. Confirm alignment by checking the DMARC aggregate reports after setup.
Step 3: DMARC Record Checklist
DMARC (Domain-based Message Authentication, Reporting and Conformance) is the policy layer that ties SPF and DKIM together. It tells receiving mail servers what to do when a message fails authentication, and it sends you regular reports showing who is sending email using your domain — including anyone who may be impersonating you.
DMARC is configured in three phases. Skipping to p=reject without a monitoring period is one of the most common causes of legitimate mail disappearing unexpectedly.
| Phase | Policy | What Happens | When to Move On |
|---|---|---|---|
| Phase 1 | p=none | All mail delivered; DMARC reports sent to your inbox for analysis | After 2–4 weeks of clean reports |
| Phase 2 | p=quarantine | Failing mail goes to spam; reports continue | After 1–2 weeks of no unexpected quarantining |
| Phase 3 | p=reject | Failing mail is blocked entirely at SMTP level — no delivery, no spam folder | Maintain; review reports quarterly |
| DMARC Checklist Item | Status |
|---|---|
| Set up an email address dedicated to receiving DMARC aggregate reports (e.g., dmarc-reports@yourdomain.co.za) | ☐ Done |
Create a TXT record in DNS: Host = _dmarc, Value = v=DMARC1; p=none; rua=mailto:your-report-address | ☐ Done |
| Wait 2–4 weeks and review aggregate reports (use a DMARC report reader tool — the raw XML is not human-readable) | ☐ Done |
| Identify any legitimate sources failing DMARC alignment, and fix SPF/DKIM for each before escalating policy | ☐ Done |
Update to p=quarantine and monitor for an additional 1–2 weeks | ☐ Done |
Update to p=reject for full protection | ☐ Done |
| Review DMARC reports quarterly to catch new sending services that may bypass authentication | ☐ Done |
The Adoption Gap Is an Opportunity
EasyDMARC's 2026 report of 1.8 million domains found that while 52.1% of domains now have a DMARC record, fewer than 9% combine enforcement with proper reporting. Most organisations are still sitting at p=none — monitoring without protection. If you reach p=reject, you have outpaced the majority of businesses competing for inbox placement.
Step 4: BIMI Record (Advanced)
BIMI (Brand Indicators for Message Identification) is the fourth layer: once SPF, DKIM, and DMARC are at p=quarantine or p=reject, you can publish a BIMI DNS record that displays your verified brand logo next to your messages in supporting inboxes — including Gmail and Yahoo Mail.
BIMI is optional and commercially useful — but worth assessing honestly before investing. Three friction points apply for South African businesses: first, Gmail's blue verified checkmark requires a VMC, which in turn requires a registered trademark on your logo — a meaningful barrier for brands without an existing trademark registration. Second, VMC issuance from Entrust or DigiCert carries a significant annual certificate fee, so it suits established brands with budget to match. Third, BIMI logo display is limited to Gmail and Yahoo Mail — Outlook desktop and Apple Mail have partial or no support as of 2026, which matters if your primary audience is B2B and uses Microsoft 365. Assess your inbox mix before committing.
| BIMI Checklist Item | Status |
|---|---|
| Confirm DMARC is at p=quarantine or p=reject (p=none is not sufficient for BIMI) | ☐ Done |
| Convert brand logo to SVG Tiny Portable/Secure format (no scripts, no external references) | ☐ Done |
| Host the SVG file at a publicly accessible HTTPS URL | ☐ Done |
| Obtain a Verified Mark Certificate (VMC) from Entrust or DigiCert if targeting Gmail's blue checkmark | ☐ Done |
Create BIMI TXT record: Host = default._bimi, Value = v=BIMI1; l=[logo URL]; a=[VMC URL if applicable] | ☐ Done |
Multiple Sending Services and Still Not Sure You're Covered?
Tell us which platforms you use — Klaviyo, Omnisend, Everlytic, HubSpot, a transactional provider — and we will map every authentication gap before your next campaign goes out.
Book a Deliverability AssessmentHow Does Email Authentication Connect to POPIA in South Africa?
Email domain authentication and POPIA compliance are separate requirements that reinforce each other. Authentication proves your domain is legitimate to inbox providers. POPIA governs whether you have the right to send to each recipient in the first place.
Under POPIA's Section 11, processing personal information for direct marketing purposes requires a lawful basis — and while consent is the most common basis for new contacts, the Act lists several lawful bases including contractual necessity, legal obligation, and legitimate interests. The Information Regulator — the statutory body that enforces both POPIA and PAIA — published a Guidance Note on Direct Marketing in December 2024 that confirms consent as the default expectation for email marketing to consumers.
Section 45 of the ECT Act requires every marketing email to carry a functional unsubscribe mechanism and for senders to be identifiable. POPIA separately requires that you disclose the source of a recipient's contact details on request. These obligations apply whether your emails land in the inbox or not — but a properly authenticated domain makes it far more likely they will be seen, acted on, and unsubscribed cleanly when the recipient chooses to.
What Authentication Does NOT Fix
SPF, DKIM, and DMARC prove you are the legitimate sender — they do not make a non-consensual send compliant with POPIA. A fully authenticated domain sending to a bought list is still a POPIA violation. Authentication and consent are both required; neither substitutes for the other. See our guide to cold email rules under POPIA for the full regulatory picture.
How Do You Verify Your Email Domain Authentication Is Working?
The final step in any email domain authentication checklist is verification. Publishing DNS records does not guarantee they are configured correctly — inbox providers check records in real time with every delivery attempt.
Use these methods to confirm your setup before your next campaign:
| Verification Method | What It Checks | Cost |
|---|---|---|
| MXToolbox (mxtoolbox.com) | SPF record syntax, DKIM key lookup, DMARC policy | Free |
| Google Workspace Toolbox (toolbox.googleapps.com) | Email header analysis confirming pass/fail per protocol | Free |
| Gmail "Show Original" | Live authentication result for a sent message (SPF: PASS / DKIM: PASS / DMARC: PASS) | Free |
| DMARC Report Reader (EasyDMARC, dmarcian) | Aggregate XML reports from inbox providers showing all sources sending from your domain | Free tier available |
DNS propagation can take up to 48 hours after creating or updating records. Lower your TTL to 3,600 seconds before making changes to speed up the process, and flush your local DNS cache before testing. For a broader look at factors affecting inbox placement, the email deliverability guide for South Africa covers sender reputation, list hygiene, and content factors alongside authentication.
Test Before You Send
Run a verification check after every change to your DNS records or email service providers — not just once at initial setup. Adding a new transactional email tool, switching ESPs, or migrating domains resets the authentication state. A quarterly authentication audit catches drift before it costs you a campaign.
Want an Authentication Audit Before Your Next Campaign?
We review your complete DNS authentication stack — SPF, DKIM, DMARC, and sending sources — and deliver a prioritised fix list within 24 hours.
Request an Authentication AuditWhy South African Businesses Choose Growth Pulse Media for Email Setup
Growth Pulse Media includes a full SPF, DKIM, and DMARC audit in every email marketing onboarding — because a misconfigured authentication stack undermines campaign ROI before a single message is sent. Many SA businesses run Google Workspace for internal mail, Klaviyo or Omnisend for marketing campaigns, and a separate provider like Pepipost or Postmark for transactional sends. Each requires its own DKIM record and counts against the SPF lookup limit. Getting all three sources authenticated without breaking each other requires a careful audit of the full sending stack, not a copied template.
Dirk built and scaled a South African ecommerce business before founding GPM — these are infrastructure problems solved in production, not sourced from a textbook. We run a limited client load by design, which means every account receives direct senior attention throughout onboarding. If your campaigns are losing inbox placement to an authentication gap, that is a fixable problem with a clear sequence of steps. We can run that sequence with you.
Who This Is NOT For
You rely entirely on your hosting provider to "handle" authentication. Most South African shared hosts generate an SPF record for their own mail servers — which covers emails sent through cPanel, but not through your ESP, CRM, or transactional provider. If you have not explicitly checked what is in your SPF record, assume it is incomplete.
You set DMARC to p=reject the same day you set it up. Without a monitoring phase, you cannot know which of your legitimate sending sources are already failing alignment. Moving to p=reject before you have read your reports is how businesses accidentally block their own order confirmation emails.
You authenticated once and never checked again. Adding a new marketing tool, switching platforms, or changing domain registrars can break authentication silently. There is no alert — you simply start landing in spam until someone notices the open rates have collapsed.
You are treating authentication as a substitute for list hygiene. A fully authenticated domain sending to disengaged, bouncing, or spam-flagging contacts will still accumulate a damaged sender reputation. Authentication is necessary — it is not sufficient. Pair it with hard bounce management and regular list cleaning.
Frequently Asked Questions
Do I need all three — SPF, DKIM, and DMARC — or can I choose?
Google and Yahoo require SPF or DKIM for all senders, and both SPF, DKIM, and a DMARC record for bulk senders (more than 5,000 emails per day), with enforcement active since February 2024. Microsoft enforced the same requirement from May 2025. For South African businesses sending regular marketing campaigns, all three are the safe minimum. DMARC without SPF or DKIM is meaningless — there is nothing for it to evaluate.
How long does email domain authentication take to set up?
The DNS record creation for SPF, DKIM, and an initial DMARC p=none policy typically takes under an hour if you have admin access to your DNS panel and your email providers' documentation open. Propagation takes up to 48 hours. The monitoring phase — reading DMARC reports and fixing alignment issues before moving to p=quarantine or p=reject — takes two to four weeks if done properly. Rushing this phase is the main cause of legitimate mail being blocked.
Will email domain authentication fix my deliverability problems?
Authentication is a prerequisite for good deliverability, not a complete solution. A properly authenticated domain that sends to low-quality lists, generates high bounce rates, or accumulates spam complaints will still see poor inbox placement. Authentication tells inbox providers you are who you claim to be — they still judge what you are sending and to whom. Pair authentication with clean list hygiene, active bounce management, and engaged-segment targeting for full inbox placement.
Does email authentication satisfy POPIA requirements?
No. POPIA compliance covers consent, data minimisation, storage limitation, and the right to opt out — authentication addresses none of those directly. POPIA email compliance requirements apply to the legality of your contact list and the content of your campaigns. Authentication satisfies the inbox provider's technical requirements; POPIA governs the legal right to send in the first place. You need both.
What should I do if my DMARC reports show sources I do not recognise?
Unknown sources appearing in DMARC aggregate reports fall into two categories: legitimate services you forgot to include in SPF (common if someone set up a new tool without informing the domain admin), or genuine impersonation attempts using your domain. Log into each source shown in the report and cross-reference against your sending stack. Legitimate misses get added to SPF and given a DKIM key. Unrecognised sources that cannot be accounted for are evidence of spoofing — which is exactly what DMARC at p=reject blocks.
Do I need separate authentication for subdomains?
Yes, if those subdomains send email. A DMARC record on your root domain covers subdomains under the sp= tag, but SPF and DKIM records must exist for each subdomain that sends independently. Subdomains commonly used for transactional mail (e.g., mail.yourbusiness.co.za) or marketing (e.g., news.yourbusiness.co.za) each need their own SPF TXT record and DKIM selector published in DNS.
Get Your Email Authentication Sorted Before Your Next Send
Growth Pulse Media works with South African businesses on the full email infrastructure stack — SPF, DKIM, DMARC configuration, Klaviyo and Omnisend integration, POPIA-compliant list management, and ongoing deliverability monitoring. We audit your current sending stack, identify every misconfiguration, and implement fixes with a clear handover. No obligation — we'll get back to you within 24 hours.
Book Your Email Authentication Review