Email in Joomla

1. The Basics: How Email Actually Works

Before touching any Joomla setting, it helps to know what happens when an email is sent. Email is not one system. It is a chain of separate services that hand a message from one to the next, a bit like the postal service moving a letter.

1.1 The Journey of One Message

When your site sends an email to This email address is being protected from spambots. You need JavaScript enabled to view it., the message passes through several stages:

Your site → a sending server (MTA) → the internet → the recipient's
mail server → the recipient's mailbox → Anna reads it

The piece that actually transports mail between servers is called an MTA (Mail Transfer Agent). It speaks a protocol called SMTP (Simple Mail Transfer Protocol). SMTP is the language servers use to say "I have a message for this address, will you take it?"

One step is easy to miss: how does the sending server know where to deliver mail for example.com? It asks DNS for the domain's MX record (Mail Exchange), which names the server that receives mail for that domain. So DNS does not just point a domain at a website; a separate MX record points the same domain at its mail server. The DNS records that protect your own outgoing mail (SPF, DKIM, DMARC) are covered in section 7 and, in full depth, in the companion Focus On article on Email Deliverability.

1.2 Two Sides of Email: Sending and Receiving

It is important to split email into two jobs that have nothing to do with each other:

• Sending uses SMTP. This is the only side a Joomla site cares about. A website sends mail; it never receives it.
• Receiving and reading uses other protocols, mainly IMAP and the older POP3. These let a person download and read mail from a mailbox.

Your Joomla site only ever sends. It does not have a mailbox and it does not check for replies. When you set "Reply To" in Joomla, replies go to a normal human mailbox somewhere else, not back to the website.

1.3 The Post Office Analogy

Think of it like sending a paper letter:

• You write the letter (Joomla builds the message).
• You drop it at the post office (Joomla hands it to a sending server over SMTP).
• The postal network carries it (servers relay it across the internet).
• It lands in a mailbox (the recipient's mail server stores it).
• The person opens their mailbox (an email client or webmail shows it).

Joomla's job ends at "drop it at the post office." Everything after that depends on whether the post office trusts you, which is exactly what SPF, DKIM, and DMARC are about. We get there in section 7.

3. How Joomla Sends Email: The Mailer Setting

Joomla offers three ways to send mail. You pick one in Global Configuration with the Mailer setting. Internally, all three end up driving PHPMailer, the well-known PHP mail library bundled with Joomla, but they differ a lot in reliability.

3.1 The Three Mailer Options

3.2 PHP Mail

The mail option asks the web server itself to send the message. It is the default and needs no configuration, which is why it is so common. The problem is that a typical web server is not a proper mail server. It often has no correct sender identity, no authentication, and a poor reputation, so the big mailbox providers quietly drop the mail or mark it as spam.

3.3 Sendmail

The sendmail option hands the message to a local mail program at a path like /usr/sbin/sendmail. It works only if your hosting actually runs such a program and has it configured well, which is increasingly rare on shared hosting.

3.4 SMTP

The smtp option tells Joomla to log in to a real mail server, exactly like an email client would, and send through it. This is the option you want in almost every case. Sections 5 and 6 explain why and how.

5. Why You Should Use SMTP

If you take one practical step from this article, make it this: set the Mailer to smtp and point it at a proper mail server. Here is why SMTP wins over the other two options.

5.1 Authentication Builds Trust

With SMTP you log in with a username and password. The sending server knows exactly who you are and is willing to vouch for your mail. PHP mail sends anonymously from a web server that mailbox providers have no reason to trust, so it is far more likely to be junked.

5.2 A Real Sender Reputation

Proper mail servers, and especially dedicated sending services, work hard to keep a clean reputation with Gmail, Outlook, and the rest. When you send through them, you borrow that good reputation. A shared web server's IP address is often already on a blocklist because some other site on it sent spam.

5.3 It Matches Your SPF and DKIM

As section 7 explains, your domain publishes a list of servers allowed to send its mail. If you send through your real mail provider's SMTP, your mail comes from a server already on that approved list, and it can be cryptographically signed. PHP mail from a random web server usually fails these checks.

5.4 Clear Errors Instead of Silent Loss

When SMTP fails, it tells you why: "authentication failed", "connection refused". PHP mail almost always reports success even when the message vanishes later, because handing the message to the operating system is all it checks. SMTP gives you something to debug.

PHP mail asks "did I hand it over?" SMTP asks "did a real mail server accept it?" Only the second question matters for delivery.

7. SPF, DKIM, DMARC, and DNS

You can configure Joomla perfectly and still land in spam. The reason lives outside Joomla, in your domain's DNS records. These three records tell the receiving mail server whether to trust mail that claims to come from your domain. They are the single biggest factor in deliverability.

7.1 A Quick Word on DNS

DNS (Domain Name System) is the phone book of the internet. It maps your domain name to addresses and also stores small text records about your domain. SPF, DKIM, and DMARC are all TXT records you add at wherever your domain's DNS is managed: your registrar, your hosting control panel, or a service like Cloudflare. They are not set in Joomla at all.

7.2 SPF: Who Is Allowed to Send

SPF (Sender Policy Framework) is a public list of the servers allowed to send mail for your domain. When mail arrives, the receiver checks whether it came from a server on that list. A simple SPF record looks like this:

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

The include: part names the sending service (here Google). If you send through Microsoft 365 or Brevo, you use their include: value instead, taken from their documentation. The ending tells receivers what to do with any server not on the list: ~all is a soft fail ("accept but mark as suspicious"), while -all is a hard fail ("reject outright"). Start with ~all while you confirm every real sender is listed, then tighten to -all. Two cautions matter: a domain may have only one SPF record, and SPF allows at most ten DNS lookups, so chaining many include: values can break it. The Email Deliverability article covers both limits in detail.

7.3 DKIM: A Tamper-Proof Signature

DKIM (DomainKeys Identified Mail) adds a cryptographic signature to every message. Your sending service signs the mail with a private key, and you publish the matching public key in DNS. The receiver checks the signature to confirm the mail really came from your domain and was not changed on the way. You normally get the exact DKIM record to paste in from your mail provider's setup screen.

7.4 DMARC: The Policy That Ties It Together

DMARC (Domain-based Message Authentication, Reporting and Conformance) tells receivers what to do when SPF or DKIM fails, and where to send reports. A gentle starting record is:

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

Start with p=none, which only monitors and reports without blocking anything. Once the reports show your real mail passes, tighten it to p=quarantine (send failures to spam) and later p=reject (refuse them). Moving too fast to reject can block your own legitimate mail, so step up gradually.

7.5 How They Work Together

SPF    → "Is this server allowed to send for the domain?"
DKIM   → "Is the signature valid and the message unchanged?"
DMARC  → "If SPF or DKIM fails, what should I do, and tell the owner."

This is exactly why section 4 insists on a From address at your own domain, and section 5 recommends SMTP through your real provider: only then does your mail come from an approved, signed source that passes all three checks.

9. Under the Hood: The Mail API (Developer View)

For developers, Joomla wraps PHPMailer in a small, clean API. You almost never touch PHPMailer directly; you ask Joomla's factory for a mailer that already has the Global Configuration settings applied.

9.1 The Key Classes

9.2 Sending a Simple Message

The modern way is to get the mailer from the factory, so it inherits your SMTP settings automatically:

use Joomla\CMS\Factory;

$mailer = Factory::getContainer()
    ->get(\Joomla\CMS\Mail\MailerFactoryInterface::class)
    ->createMailer();

$mailer->addRecipient(This email address is being protected from spambots. You need JavaScript enabled to view it.', 'Anna');
$mailer->setSubject('Hello from Joomla');
$mailer->setBody('This message used the site mail settings.');

if ($mailer->Send() === true) {
    // delivered to the transport
}

Because the factory applies the Mailer, host, port, and login from configuration.php, your code does not hard-code any SMTP details. Change the Global Configuration once and every piece of code that uses the factory follows.

9.3 Where the Settings Come From

configuration.php  ($mailer, $smtphost, $smtpport, $smtpuser, ...)
  └─ MailerFactory reads these values
     └─ builds a configured PHPMailer instance
        └─ your $mailer->Send() hands the message over via the chosen transport

This is why a well-written extension (like RSForm Pro) "just works" once you fix Global Configuration: it builds its mailer through this same factory rather than inventing its own transport.

11. Deliverability: Getting Into the Inbox

Email has no search engine ranking, but it has the same kind of battle: reaching the inbox instead of the spam folder. A correctly built message is wasted if it never arrives. The factors that decide this are, in order of impact:

• SPF, DKIM, and DMARC: the DNS records from section 7. This is the biggest lever, and it lives outside Joomla.
• Authenticated SMTP: send through a real, reputable mail server, not raw PHP mail.
• Reverse DNS (PTR): the sending server's IP address should resolve back to a matching hostname. Your SMTP provider normally handles this, which is another reason to send through one.
• A real From address at your own domain: never a free Gmail or Outlook address, and never a domain you do not control.
• A matching Reply To: a real, monitored mailbox so replies do not vanish.
• Honest, clean subjects and content: avoid all-caps, "FREE!!!", and link-only bodies that look like spam.
• A plain-text part alongside HTML: strict filters like to see clean text too.

Notice how few of these live inside Joomla. You configure the transport in Joomla, but you win the inbox at the DNS and reputation level.

13. Best Practices

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

• Set the Mailer to smtp and send through a real, reputable mail server.
• Use a From address at your own domain, never a free Gmail or Outlook address.
• Add SPF, DKIM, and DMARC in DNS. They decide whether you reach the inbox.
• Start DMARC at p=none, read the reports, then tighten gradually.
• For Google and Microsoft 365, use an App Password or enable SMTP AUTH, not your login password.
• For busy sites, use a transactional mail service built for sending.
• Always click Send Test Mail after changing settings, and read the error if it fails.
• Know which extensions use Joomla's mailer (like RSForm Pro) and which keep their own (like AcyMailing).
• Keep configuration.php private; it holds your SMTP password in readable form.
• Trap mail on staging with a catcher like MailHog or Mailpit so tests never reach real people.

15. Summary

Email looks simple from the outside, but a message from your Joomla site passes through several independent systems before it reaches a person. Understanding that chain is what turns "my mail does not work" into a problem you can actually fix.

• Email is sending and receiving, and a website only ever sends, over SMTP.
• Webmail and email clients are for people reading mail; a site sends automatically with no mailbox.
• The Mailer setting in Global Configuration chooses PHP mail, Sendmail, or SMTP. Choose SMTP.
• SMTP through a real provider gives you authentication, reputation, and clear errors.
• Google and Microsoft 365 need an App Password or enabled SMTP AUTH, not a plain login.
• SPF, DKIM, and DMARC in DNS decide whether you reach the inbox, and they live outside Joomla.
• Extensions differ: some, like RSForm Pro, use Joomla's mailer; others, like AcyMailing, keep their own.

The key mindset is the split between sending and delivering. Joomla sends the message; your transport and your DNS decide whether it arrives. Get both right and your site speaks to its users reliably, every time.

If your Joomla mail still lands in spam, fails for one extension but not another, or vanishes without a trace, it usually comes down to the transport and DNS layers described here. A careful look at the mailer settings, the SMTP provider, and the SPF, DKIM, and DMARC records almost always finds the cause, and getting them right once means you can finally stop worrying about whether your site's email arrives.