Skip to content
In this article10 sections

Plesk can host mailboxes for your domain, and it can send mail for applications too. The mail only reaches the inbox when three DNS records agree: SPF says which servers may send for your domain, DKIM signs each message, and DMARC tells receivers what to do when the first two fail. Plesk shows the records it needs, but the DNS change, the test and the policy are your job. This guide sets up the three records for a domain hosted on Plesk, checks each one, and explains the order to change them in.

SiteHarbour’s business email sets up SPF, DKIM and DMARC for you, with spam and virus filtering. If you run mailboxes in Plesk yourself, the steps below cover the same records.

Before you start

  • Access to the DNS zone for the domain, either in Plesk or at the registrar.
  • A mailbox you read, for the DMARC reports.
  • A list of every service that sends mail for the domain: the website contact form, the invoicing tool and any newsletter provider.

Step 1: Check the MX record

The MX record tells other servers where to deliver mail. In Plesk, open the domain’s DNS settings and check the MX record points at the mail server for the hosting plan. From a terminal:

nslookup -type=MX example.com

Expected: the host name that Plesk lists for mail. If the MX points somewhere else, mail goes to the old host, and no SPF or DKIM record fixes that.

Step 2: Publish one SPF record

SPF is a TXT record at the root of the domain. It lists the servers allowed to send for it. Plesk creates a default SPF record when mail is enabled. Edit that record rather than adding a second one, because two SPF records make both invalid. A record for a domain that sends from the Plesk server and from one newsletter service looks like this:

example.com. TXT "v=spf1 mx a include:_spf.newsletter.example -all"

Replace the include with the service’s own value, as the service gives it. Keep the record to one line, and end it with -all once every sender is listed. Use ~all while you are still finding the senders.

Check it:

nslookup -type=TXT example.com

Expected: exactly one line that starts with "v=spf1.

Step 3: Turn on DKIM

In Plesk, open the mail settings for the domain and enable DKIM signing. Plesk generates a key pair and shows the DNS record for the public key, with a selector name, usually default. Add the record as shown, to the name Plesk gives it:

nslookup -type=TXT default._domainkey.example.com

Expected: a long string that starts with v=DKIM1. The private key stays on the server, and is never entered in DNS.

Step 4: Publish a DMARC policy in monitor mode

DMARC tells receivers what to do with mail that fails SPF or DKIM, and it sends you a report. Start in monitor mode, so you can see every sender before you block any:

_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:[email protected]; adkim=r; aspf=r"

Use an address you read for the reports. The reports arrive as XML files, and a tool or a service can make them readable. Leave the policy at none for at least two weeks, and read the reports during that time. The full rollout to quarantine and reject is covered in how to set up DMARC without losing email.

Step 5: Send a test and read the headers

Send a message from a mailbox on the domain to a Gmail address. Open the message and view its original headers. Look for three results: spf=pass, dkim=pass and dmarc=pass. If one fails, fix that record before you move on. The three records share one DNS zone, but each one checks something different.

Step 6: Check the senders in the reports

Each DMARC report lists the servers that sent mail as the domain. A legitimate sender that is not in your SPF record shows up as a failure. Add it to SPF, or stop it sending as the domain. A sender you do not recognise is a reason to find out more before you tighten the policy.

Step 7: Tighten the policy

When the reports show that every legitimate sender passes, move to p=quarantine, then to p=reject, a few weeks apart. Each step blocks more fake mail and risks more real mail, so check the reports between steps. A domain on reject with an incomplete SPF record loses real mail, and that loss is silent.

Common mistakes

  • Two SPF records. Merge them into one.
  • Starting DMARC at reject. Use monitor mode first.
  • Forgetting a sender. A form, an invoice tool or a newsletter that is not in SPF fails DMARC.
  • Using the DKIM private key in DNS. Only the public key goes in DNS.
  • Not waiting for DNS. A record can take time to appear. Check again before you change anything else.

Frequently asked questions

Which record do I set up first?

Check the MX, then publish the SPF record, then turn on DKIM, then DMARC in monitor mode. That order means each record is in place before the next one depends on it.

Do I need all three records?

For reliable delivery, yes. Each one covers a different check, and DMARC depends on at least one of the others passing with your domain.

Will DMARC stop spam from using my domain?

At reject it blocks mail that fails the checks, which stops most spoofing of your domain. It does not stop someone sending from a different domain.

Why does the report show failures I do not understand?

Usually a forwarding service or a form that sends mail on your behalf. Check the sender’s IP in the report and match it to the service.

Plesk mail delivers when the MX, SPF, DKIM and DMARC records agree. Check the MX, publish one SPF record, turn on DKIM, and start DMARC in monitor mode. Read the reports, add every legitimate sender, and only then move towards reject. For the wider email setup, read how to set up email accounts and SPF in cPanel, which covers the same records on a cPanel account.

Share this guide

Keep exploring