On this page

# Topics

Email deliverability in Joomla

Q: What are SPF, DKIM and DMARC?

SPF (Sender Policy Framework) verifies which mail servers are authorized to send email on behalf of your domain. DKIM (DomainKeys Identified Mail) adds a digital signature to each email, allowing receiving servers to verify that the message has not been altered in transit. DMARC (Domain-based Message Authentication, Reporting and Conformance) combines SPF and DKIM by telling receiving mail servers how to handle unauthenticated emails and providing reports about authentication results.

27 June 2026

You can configure Joomla's mail settings perfectly, send through a proper SMTP server, and still watch your messages land in the spam folder. When that happens, the cause is almost never inside Joomla. It lives in your domain's DNS, in three small text records that decide whether the receiving mail server trusts you: SPF, DKIM, and DMARC.

This article is the deep companion to the Focus On article on Email and Joomla. That one explains how to send mail; this one explains how to get it delivered. It covers what DNS is and how mail finds your server, the three authentication records in detail, the alignment rule that trips up so many people, reverse DNS and other signals, the exact records for Google and Microsoft 365, and how to verify everything afterwards.

Sending mail is a Joomla setting. Reaching the inbox is a DNS project.

The goal is to give owners, administrators, and developers enough understanding of email authentication to set it up once, prove it works, and stop guessing why mail goes missing.

1. The Basics: DNS and Email

Email authentication is built entirely on DNS, so a short refresher pays off before we touch SPF.

1.1 What DNS Is

DNS (Domain Name System) is the phone book of the internet. It maps a domain name to addresses and stores small records about the domain. You do not edit DNS in Joomla. You edit it wherever your domain is managed: your registrar, your hosting control panel, or a DNS service like Cloudflare.

1.2 The Records That Matter for Mail

Record	Job in email
`MX`	Names the server that receives mail for your domain.
`TXT`	Holds SPF, DKIM, and DMARC as text. Almost all authentication lives here.
`A` / `AAAA`	Maps a hostname to an IPv4 / IPv6 address.
`PTR`	Reverse lookup: maps a sending IP back to a hostname.
`CNAME`	An alias to another hostname; some providers use it for DKIM.

SPF, DKIM, and DMARC are all published as TXT records (a few providers use CNAME for DKIM). They protect outgoing mail. The MX record is the separate one that points your domain at its incoming mail server.

1.3 Two Numbers to Know: TTL and Propagation

Each DNS record has a TTL (Time To Live), the number of seconds other servers may cache it. After you change a record, the old value can linger until the TTL expires. This is called propagation. Plan for changes to take anywhere from minutes to a day to be visible everywhere, and lower the TTL before a planned change so the switch is faster.

2. The Three Records at a Glance

Before the detail, here is the whole picture in one place. Each record answers a different question for the receiving server.

Record	Answers the question	Where you get it
SPF	Is this server allowed to send for the domain?	You write it, listing your senders.
DKIM	Is the signature valid and the message unchanged?	Your mail provider gives you the record.
DMARC	If SPF or DKIM fails, what should I do, and tell the owner.	You write the policy.

Incoming message claims to be from you
  └─ SPF    → was it sent from an approved server?
  └─ DKIM   → is the cryptographic signature valid?
  └─ DMARC  → do SPF or DKIM pass AND align with the From domain?
                  if not, apply the policy (none / quarantine / reject)

The crucial idea that ties them together is alignment, covered in section 5. For now, remember that DMARC is not a fourth check bolted on; it is the referee that reads the SPF and DKIM results and enforces a rule.

3. SPF: Authorising Your Senders

SPF (Sender Policy Framework) is a public list of the servers allowed to send mail for your domain. When a message arrives, the receiver checks whether the sending server appears on that list.

3.1 What an SPF Record Looks Like

Type:  TXT
Name:  @                                  (your domain root)
Value: v=spf1 include:_spf.google.com ~all

It always starts with v=spf1 and ends with an all rule. In between sit one or more mechanisms that name approved senders.

3.2 The Common Mechanisms

Mechanism	Meaning
`include:domain`	Also trust the senders listed by that domain (used by Google, Microsoft, Brevo, and so on).
`ip4:1.2.3.4`	Trust this exact IPv4 address (your own mail server).
`ip6:...`	Trust this IPv6 address.
`a`	Trust the domain's own A record IP.
`mx`	Trust the servers in the domain's MX records.

3.3 Soft Fail vs Hard Fail: the all Rule

The final all mechanism decides what happens to any server not matched above it. The qualifier in front of it is what matters:

Ending	Name	Effect on unlisted senders
`~all`	Soft fail	Accept, but mark as suspicious. Safe to start with.
`-all`	Hard fail	Reject. The strict, recommended end state.
`+all`	Pass all	Never use this; it authorises the whole internet.

Begin with ~all while you confirm every legitimate sender is listed, then tighten to -all once you are sure.

3.4 Two Hard Limits

SPF has two rules that quietly break setups:

One record only. A domain may have exactly one SPF TXT record. If you add a second when you start using a new provider, both become invalid. Merge the include: values into a single record instead.
Ten DNS lookups. SPF allows at most ten DNS lookups while it is being evaluated. Each include: can trigger more. Chain too many providers and SPF returns a permanent error, which counts as a failure. If you hit this, use SPF flattening: replace some include: values with the actual ip4: ranges, or use a provider that keeps your lookup count low.

4. DKIM: Signing Your Mail

DKIM (DomainKeys Identified Mail) adds a tamper-proof signature to every message. Where SPF checks the server, DKIM checks the message itself.

4.1 How It Works

DKIM uses a key pair. Your sending service holds a private key and signs each outgoing message with it. You publish the matching public key in DNS. The receiver fetches the public key, checks the signature, and confirms two things: the mail really came from your domain, and nobody changed it on the way.

You send  → provider signs with private key  → DKIM-Signature header added
Receiver  → reads the signature, fetches your public key from DNS  → verifies

4.2 Selectors

A domain can have several DKIM keys at once (for different providers, or for key rotation). DKIM tells them apart with a selector, a short name in the signature. The selector points to the exact DNS record holding that key:

Signature contains:  s=selector1
DNS record lives at: selector1._domainkey.yourdomain.com

You almost never invent these by hand. Your mail provider (Google, Microsoft 365, Brevo, and so on) shows you the exact record to paste in, selector included. Your job is to copy it into DNS faithfully.

4.3 A Practical Note

DKIM records are long and easy to corrupt when copying. A single missing character makes the signature fail. Paste carefully, do not add line breaks or quotes the provider did not include, and then verify with a checking tool (section 8) before you trust it.

5. DMARC: The Policy and Alignment

DMARC (Domain-based Message Authentication, Reporting and Conformance) ties SPF and DKIM together. It tells receivers what to do when authentication fails and asks them to send you reports.

5.1 The Record

Type:  TXT
Name:  _dmarc                              (a subdomain label)
Value: v=DMARC1; p=none; rua=mailto:This email address is being protected from spambots. You need JavaScript enabled to view it.

Tag	Meaning
`p`	The policy: `none`, `quarantine`, or `reject`.
`rua`	Where to send aggregate (summary) reports.
`ruf`	Where to send forensic (per-message) reports, if offered.
`sp`	An optional separate policy for subdomains.

5.2 Alignment: the Part Everyone Misses

This is the single most misunderstood point in email authentication. DMARC does not just ask "did SPF or DKIM pass?" It asks "did they pass and match the domain in the visible From address?" That match is called alignment.

So a message can pass SPF for the provider's domain yet still fail DMARC, because the passing domain was not your From domain. This is exactly why the Email and Joomla article insists the From address use your own domain, and why you sign with DKIM for that same domain. Alignment is what turns a technical pass into a trusted one.

5.3 The Three Policies

Policy	What the receiver does on failure
`p=none`	Nothing. Only monitors and reports. The safe starting point.
`p=quarantine`	Sends failing mail to the spam folder.
`p=reject`	Refuses failing mail outright. The strict end state.

5.4 The Reports

With rua set, mailbox providers email you a daily aggregate report: an XML summary of how much mail claimed to be from your domain, from which servers, and whether it passed. These reports are how you discover a forgotten sender (a CRM, a newsletter tool, your Joomla host) before you tighten the policy and accidentally block it.

5.5 A Safe Rollout

Publish p=none with a rua address. Block nothing yet.
Read the reports for a week or two. Make sure every real sender passes and aligns.
Move to p=quarantine. Watch the reports again.
Finally move to p=reject. Now nobody can spoof your domain.

Jumping straight to reject before the reports are clean is the fastest way to block your own legitimate mail.

6. Reverse DNS and Other Signals

SPF, DKIM, and DMARC are the big three, but a few more signals affect whether you reach the inbox.

6.1 Reverse DNS (PTR)

A PTR record maps a sending IP address back to a hostname, the reverse of a normal lookup. Receivers distrust mail from an IP with no matching reverse record. You usually cannot set this yourself; it belongs to whoever owns the IP. This is another strong reason to send through a reputable SMTP provider, which keeps proper reverse DNS for its sending IPs.

6.2 HELO / EHLO

When two mail servers connect, the sender greets the receiver with a HELO or EHLO command and names itself. A greeting that matches real DNS looks legitimate; a mismatched or missing one looks suspicious. Again, a good SMTP provider handles this correctly for you.

6.3 Greylisting

Greylisting is a spam defence where the receiver temporarily rejects mail from an unknown sender and asks it to try again later. Real mail servers retry and get through; many spam scripts never do. The visible effect is a short, one-time delay on the first message to a new recipient. It is normal and needs no action.

6.4 Blacklists (Blocklists)

If your sending IP or domain gets reported for spam, it can land on a public blocklist, and mail from it is refused or junked. Shared hosting IPs are often already listed because of other sites. You can check your status with a tool like MXToolbox (section 8). The cleanest fix is to send through a dedicated provider whose reputation you can rely on.

7. Setting It Up for Common Providers

Here are typical records for the most common senders. Always copy the exact values from your provider's own setup screen, because they change and your DKIM record is unique to you.

7.1 Google Workspace

SPF    TXT  @        v=spf1 include:_spf.google.com ~all
DKIM   TXT  google._domainkey   (the long key Google generates for you)
DMARC  TXT  _dmarc   v=DMARC1; p=none; rua=mailto:This email address is being protected from spambots. You need JavaScript enabled to view it.

In Google's admin console you generate the DKIM key, publish the record, then click "Start authentication." Use an App Password in Joomla's SMTP settings, as the Email and Joomla article explains.

7.2 Microsoft 365

SPF    TXT  @        v=spf1 include:spf.protection.outlook.com ~all
DKIM   CNAME selector1._domainkey  → (target shown in the M365 portal)
       CNAME selector2._domainkey  → (second target for key rotation)
DMARC  TXT  _dmarc   v=DMARC1; p=none; rua=mailto:This email address is being protected from spambots. You need JavaScript enabled to view it.

Microsoft 365 uses two CNAME records for DKIM so it can rotate keys automatically. You enable DKIM in the Microsoft Defender portal after the CNAMEs exist.

7.3 A Transactional Service (Amazon SES, Brevo, Postmark, and so on)

SPF    TXT  @        v=spf1 include:(provider's spf domain) ~all
DKIM   CNAME/TXT     (three or more records the provider lists for you)
DMARC  TXT  _dmarc   v=DMARC1; p=none; rua=mailto:This email address is being protected from spambots. You need JavaScript enabled to view it.

These services walk you through "verify your domain," which simply means adding the DNS records they show. Once verified, you paste their SMTP host, username, and API-key password into Joomla.

7.4 If You Use More Than One Sender

Many sites send from two places: Joomla system mail through one provider and newsletters (for example AcyMailing) through another. Both must be authorised. Combine their senders in the single SPF record and add a DKIM record for each, mindful of the ten-lookup limit from section 3.4.

8. Verifying and Monitoring

Never assume a DNS change worked. Check it, then keep an eye on it.

8.1 Command-Line Checks

If you have shell access, these read your records directly:

dig example.com TXT                       show SPF and other TXT records
dig _dmarc.example.com TXT                show the DMARC record
dig selector1._domainkey.example.com TXT  show a DKIM key
dig example.com MX                        show the mail server
nslookup -type=TXT example.com            the same on Windows

8.2 Online Tools

Tool	What it tells you
Mail Tester	A spam score plus SPF, DKIM, and DMARC results for a real message.
MXToolbox	DNS, MX, blacklist, and SMTP checks.
Google Postmaster Tools	Your domain's reputation and delivery with Gmail.
DMARC report viewers	Turn the daily XML aggregate reports into readable summaries.

8.3 Reading the Result in a Real Email

The quickest single check: send yourself a message, open it in Gmail, and choose "Show original." Gmail prints the verdict plainly:

SPF:   PASS with IP 1.2.3.4
DKIM:  PASS with domain yourdomain.com
DMARC: PASS

Three passes mean your setup is sound. Any fail tells you exactly which record to revisit. The Focus On article on Troubleshooting Joomla Email goes deeper into reading these headers.

9. How This Connects to Joomla

None of these records are set in Joomla, yet they decide whether Joomla's mail arrives. Three Joomla-side choices make authentication line up:

From address on your own domain. In Global Configuration, set From Email to an address at the domain you authenticated, so SPF and DKIM can align with it. A free Gmail From address can never align with your domain's DMARC.
Send through the provider you authorised. Point Joomla's SMTP at the same provider whose include: is in your SPF and whose DKIM you published. Then Joomla's mail comes from an approved, signed source.
Mind extensions with their own mail config. An extension like AcyMailing that sends through a different service must also be covered by your SPF and DKIM, or its mail will fail DMARC even though Joomla's own mail passes.

In short, authentication is a DNS project, but Joomla must be set up to match what you published. The Email and Joomla article covers that Joomla side step by step.

10. Common Mistakes and Pitfalls

10.1 Two SPF Records

Symptom: You added a provider and now SPF fails for everything.

Fix: A domain may have only one SPF record. Merge all include: values into a single v=spf1 ... ~all record.

10.2 SPF Lookup Limit Exceeded

Symptom: SPF returns a permanent error although the record looks correct.

Fix: You passed the ten-DNS-lookup limit. Remove unused include: values or flatten some to ip4: ranges.

10.3 DMARC Passes Technically but Fails on Alignment

Symptom: SPF says pass, yet DMARC says fail.

Fix: The passing domain did not match your From domain. Send from your own domain and sign with DKIM for it, so the result aligns.

10.4 Jumping Straight to p=reject

Symptom: After setting DMARC, some of your own mail disappears.

Fix: Roll back to p=none, read the reports, confirm every real sender passes, then tighten gradually.

10.5 A Corrupted DKIM Record

Symptom: DKIM fails even though the key is published.

Fix: A character was dropped or a line break added when pasting. Re-copy the exact record from the provider and verify with a tool.

10.6 Forgetting a Second Sender

Symptom: System mail is fine, but newsletters land in spam.

Fix: The newsletter service is not in your SPF or has no DKIM. Authorise every service that sends as your domain.

11. Best Practices

If you remember only a few things from this article, remember these:

Publish all three records: SPF, DKIM, and DMARC. Together they make the inbox.
Keep exactly one SPF record and stay under ten DNS lookups.
Start SPF at ~all and DMARC at p=none, then tighten once the reports are clean.
Sign with DKIM for the same domain you put in the From address, so DMARC aligns.
Send through a reputable provider so reverse DNS, HELO, and reputation are handled for you.
Authorise every sender, including newsletter and CRM tools, not just Joomla.
Verify with a tool after every change, and watch DMARC reports over time.
Lower a record's TTL before a planned change so the switch propagates faster.

12. Quick Reference

WHERE          Your DNS host (registrar / hosting panel / Cloudflare), NOT Joomla

SPF    TXT @         v=spf1 include:provider ~all   (one record, max 10 lookups)
       ~all soft fail (start)   -all hard fail (end)   +all never
DKIM   TXT/CNAME selector._domainkey    public key from your provider
DMARC  TXT _dmarc    v=DMARC1; p=none; rua=mailto:you@domain
       p=none monitor  →  p=quarantine  →  p=reject
ALIGN  From domain must match the SPF/DKIM domain, or DMARC fails
PTR    reverse DNS on the sending IP   (provider's job)

GOOGLE        SPF include:_spf.google.com         DKIM google._domainkey
MICROSOFT 365 SPF include:spf.protection.outlook.com  DKIM 2x CNAME selectors

VERIFY  dig example.com TXT
        dig _dmarc.example.com TXT
        Mail Tester / MXToolbox / Google Postmaster / "Show original"

JOOMLA SIDE   From Email on your own domain + SMTP via the authorised provider

13. Summary

Deliverability is decided outside Joomla, in three DNS records that tell the world your mail is genuine:

SPF lists the servers allowed to send for your domain. One record, under ten lookups, ending in ~all then -all.
DKIM signs each message with a key, proving it is yours and unchanged, identified by a selector.
DMARC sets the policy and sends reports, and enforces alignment with your From domain.
Reverse DNS, HELO, greylisting, and blocklists are smaller signals a good provider handles for you.
Joomla must match what you publish: a From address on your domain, sent through the authorised provider.

Set these up once, verify them with a real test message, and watch the reports as you tighten the policy. If your Joomla site sends mail that still lands in spam despite correct SMTP settings, the answer is almost always here, in the DNS. Getting SPF, DKIM, and DMARC right is the difference between mail that technically sends and mail that actually arrives, and it is well worth an afternoon to do properly.

Peter Martin

Joomla Specialist

Peter is a Joomla specialist and a Linux admin for fast, secure and scalable websites.

Frequently Asked Questions

Why do my emails end up in the spam folder?

Emails may end up in spam or do not arrive at all because your domain lacks proper authentication (SPF, DKIM or DMARC), your server has a poor sender reputation, your content triggers spam filters, or recipients rarely engage with your emails.

How can I improve email deliverability?

Configure SPF, DKIM and DMARC correctly, use a reputable SMTP server, and maintain a good sender reputation. Send relevant emails, keep your mailing lists up to date, avoid spam-triggering content, and regularly test your email authentication to ensure messages reach the inbox.

What are SPF, DKIM and DMARC?

SPF (Sender Policy Framework) verifies which mail servers are authorized to send email on behalf of your domain.
DKIM (DomainKeys Identified Mail) adds a digital signature to each email, allowing receiving servers to verify that the message has not been altered in transit.
DMARC (Domain-based Message Authentication, Reporting and Conformance) combines SPF and DKIM by telling receiving mail servers how to handle unauthenticated emails and providing reports about authentication results.

Does using SMTP improve email deliverability?

Yes. Using a reliable SMTP service or properly configured mail server improves authentication, reputation and delivery rates. However, SMTP alone is not enough without SPF, DKIM and DMARC.

How can I check if my email authentication is working?

You can use online tools to verify your SPF, DKIM and DMARC records, inspect email headers, and test whether your messages pass authentication before sending them to customers or subscribers.