Email spoofing is when someone sends a message with your domain in the "From" address, even though it didn't come from you or your mail server. The fix isn't a single setting: it's three DNS records working together. SPF says which servers are allowed to send for your domain, DKIM signs your messages so receivers can verify they weren't altered, and DMARC ties the two together and tells receiving mail servers what to do when a message fails both checks. If any one of the three is missing, spoofed mail has an easier path into your recipients' inboxes, or your own mail lands in spam because it looks unverified.
Why spoofing works in the first place
The "From" address in an email is just a header. Nothing about basic email protocol stops a sender from typing any address they want into it, the same way nothing stops someone from writing any return address on a paper envelope. Without authentication records, a receiving mail server has no way to check whether a message claiming to be from billing@yourdomain.com actually came from a server you control.
This is why spoofed mail is so often used for invoice fraud, fake password reset emails, and phishing that impersonates a company's own staff. The attacker doesn't need access to your server or your mailbox. They need your domain name and a mail server willing to send with a forged header.
SPF: authorizing which servers can send
SPF (Sender Policy Framework) is a TXT record at your domain's root listing the mail servers allowed to send on your behalf. When a message arrives, the receiving server checks the sending IP against your SPF record. If the IP isn't listed, the message fails SPF.
SPF has a real limitation: it only checks the server that made the SMTP connection, not the visible "From" address the recipient sees. A message can pass SPF while still showing a spoofed From address, if the failing alignment isn't caught by DMARC. DMARC closes that gap, described below.
DKIM: proving the message wasn't altered
DKIM adds a cryptographic signature to outgoing mail, so the receiving server can confirm the message really was signed by a server holding your domain's private key and that nothing in it changed in transit. See DKIM: what it is and why your email needs it for how the signing and verification actually works.
DKIM alone doesn't stop spoofing either: a forged message won't have a valid signature from your domain, but without a policy telling the receiver what to do about that, some servers deliver it anyway. DMARC adds that policy.
DMARC: the enforcement layer
DMARC checks that the domain in the visible From address lines up with the domain that passed SPF or DKIM, a requirement called alignment. A message that passes SPF for one domain but shows a different domain in From still fails DMARC. This is precisely the alignment gap that lets spoofed mail slip past SPF or DKIM individually.
DMARC also publishes a policy: p=none takes no action but sends you reports, p=quarantine sends failing mail to spam, and p=reject blocks it outright. Full setup steps, including the exact TXT record and why you should never jump straight to p=reject, are covered in DMARC: setup, policies, and the Gmail/Yahoo rules.
Checking your current setup
If you're not sure whether your domain is exposed to spoofing, the fastest check is cPanel's Email Deliverability tool, which compares your domain's SPF and DKIM records against what your mail server expects and flags anything missing or mismatched. A basic DMARC record at p=none (monitor-only) may already be in place on your domain; moving to p=quarantine or p=reject takes deliberate setup, covered in the DMARC article above.
If you're setting up a new domain for outbound mail, especially for a new marketing or transactional sending address, pair authentication with a gradual sending ramp. A domain with perfect SPF, DKIM and DMARC can still land in spam if it suddenly sends high volume with no sending history. See warming up a new sending domain for the ramp schedule.
When to open a ticket
If you've confirmed SPF and DKIM are valid but customers or partners still report receiving spoofed mail claiming to be from you, or you're seeing DMARC reports listing a sending source you don't recognize and can't identify, open a ticket from the portal's Support section and describe what you're seeing so support can investigate.