Skip to main content
Gmail and Yahoo require incoming mail to be authenticated. Without SPF or DKIM in place, mail from your domain is rejected or sent to spam — not occasionally, but as policy. A domain with no DMARC record is treated with more suspicion again. If your mail has started going to spam or bouncing, this is the first place to look.
cPanel does most of it for you. Open Email Deliverability in the Email section of cPanel and look at your domain. Anything missing or wrong shows a Repair button that fixes it in place.The rest of this page covers what Repair cannot do: DMARC, third-party senders, and domains whose DNS lives somewhere else.

Two rules that cause most of the problems

One SPF record per domain, no exceptions

A domain may have exactly one SPF record. If you use several services to send mail — your hosting, a marketing platform, a transactional provider — you do not add an SPF record for each. You merge their include directives into the single record. Right:
Wrong — two records, and both will be ignored or fail:
When a provider gives you “an SPF record to add”, take the include: part out of it and add that to your existing record. If your DNS editor refuses a new TXT record at the root because one exists, that is the reason — edit the existing record instead of adding another.

Records only work where your nameservers point

If your nameservers point at an external provider, records you add in cPanel will not resolve. They will look correct in cPanel and do nothing at all. Check where your domain is delegated first. If DNS is elsewhere — Cloudflare, your registrar, an IT provider — you have two options:
  • Copy the SPF, DKIM and DMARC values from cPanel into that provider’s DNS panel, or
  • Point your nameservers at us, after which cPanel manages them — see Pointing a domain at your hosting

The three records

SPF — which servers may send as you

SPF lists the servers allowed to send mail for your domain. Mail from anywhere else fails the check. In cPanel: Email Deliverability → Manage, then look at SPF. Your record must include the right value for your product: If it is missing: click Customize, then under Include List (INCLUDE) click Add A New “+include” Item, enter the value without the include: prefix, and click Install A Customized SPF Record.
550 5.7.1 on outgoing mail means the sending IP is not authorised by your SPF record. Usually the hosting include is missing, or a second SPF record has been added and broken the first.

DKIM — a signature proving the mail is unaltered

DKIM signs each message with a private key. The recipient fetches your public key from DNS and checks the signature. A failed signature means the message was forged or altered. In cPanel: Email Deliverability → Manage, then DKIM. If it is not enabled, Repair sets it up.

DMARC — what to do when SPF or DKIM fails

DMARC tells recipients how to treat mail that fails the other two checks, and is what Gmail and Yahoo look for to decide how much to trust you. cPanel does not create it. Add it yourself in Zone Editor: p=none means “monitor, do not act”. That is the right starting point — it satisfies the requirement without risking your own mail.
Do not jump to p=reject with strict alignment. A record combining p=reject with adkim=s and aspf=s makes recipients drop messages that fail even minor alignment checks, including legitimate mail you sent. The symptom is a 550 Spam classified bounce.If that is happening, relax the alignment to adkim=r; aspf=r, or change the policy to p=quarantine while you sort it out.

Reverse DNS (PTR)

Resolves your sending IP back to a hostname. Another signal recipients use. Visible under REVERSE DNS (PTR) in Email Deliverability; changes to it need a support ticket.

After you change anything

Allow 15 to 30 minutes for new DKIM and DMARC records to resolve globally. Check with a DNS lookup tool rather than by sending test messages, which tells you less and risks tripping spam filters.

Adding a third-party sending service

Marketing and transactional providers each need their own DNS entries. The pattern is nearly always the same:
  1. A DKIM record as a TXT entry, using the exact host the provider specifies
  2. Their include: merged into your existing SPF record — not added as a new one
Provider-specific things worth knowing: If your nameservers point elsewhere, all of these go in that provider’s DNS panel, not cPanel.
Running more than one sending service? Check their records do not conflict, and keep every include in the single SPF record. If you use several platforms you can also point DMARC reports at whichever provider you want to read them.

When the problem is an incoming message

Sometimes mail to you is rejected because the sender’s authentication is broken — they publish a strict DMARC policy but their SPF or DKIM does not match it, so receiving servers refuse the message to protect you. Nothing at our end can fix that. The sender has to correct their own records with their own provider. As a short-term workaround you can add them to your safe senders list, or ask us to whitelist their domain.