Getting email from a .pk domain into the inbox

Email records are step six of the domains, hosting and deployment guide. They are the step almost everyone skips.

The contact form works. The confirmation email sends. The client says they never received it, you check, and it is in their spam folder alongside offers for extended car warranties.

What is happening: a receiving mail server has no way to know that the message claiming to come from your domain actually came from you, unless your domain publishes records saying which services are allowed to send on its behalf. Three records do that job. Publish all three and the message goes to the inbox. Publish none and a new domain sending its first transactional email is treated as exactly what it looks like.

The three records, in the order they matter

SPF lists which servers may send mail as your domain. One TXT record on the apex, and you get exactly one SPF record, not several. If you already have one and you add a mail service, you edit the existing record rather than adding a second, because two SPF records is a configuration error that fails rather than combining.

Type: TXT   Name: @   Value: v=spf1 include:_spf.yourprovider.com ~all

DKIM signs each outgoing message cryptographically so the receiver can verify it was not altered and did come from an authorised sender. Your mail provider generates the key and gives you a hostname and value to publish. It is usually a CNAME, sometimes a TXT, and the hostname includes a selector chosen by the provider.

Type: CNAME   Name: <selector>._domainkey   Value: <provided by your mail service>

DMARC tells receiving servers what to do when SPF or DKIM fails, and gives you a reporting address so you find out. It is the one most people skip, and skipping it means the other two run with no enforcement policy and no visibility.

Type: TXT   Name: _dmarc   Value: v=DMARC1; p=none; rua=mailto:[email protected]

Start at p=none, which changes nothing about delivery and only asks for reports. Read the reports for a few weeks. Move to p=quarantine once you are confident everything legitimate is passing. Going straight to p=reject on a live domain is how a business discovers, loudly, that its accounting software was sending invoices through a service nobody documented.

Doing this in the PKNIC panel

Nothing above is .pk specific. The friction is, in the same way pointing a PKNIC domain at a host is more work than it should be.

Entering a DMARC record means creating a TXT record with the name _dmarc, and panels vary in whether they want the bare label or the full hostname. If _dmarc is rejected, try _dmarc.yourdomain.pk. The same applies to the DKIM selector hostname, which is longer and contains a dot before _domainkey, and is the one most likely to be rejected on a first attempt.

Some panels quietly append the domain to whatever you type, so entering the full hostname produces _dmarc.yourdomain.pk.yourdomain.pk, which resolves to nothing and looks fine in the form. Verify every record after saving rather than trusting the panel:

dig +short TXT yourdomain.pk            # SPF
dig +short TXT _dmarc.yourdomain.pk     # DMARC
dig +short CNAME <selector>._domainkey.yourdomain.pk   # DKIM

If a record does not come back, it is not published, whatever the panel shows.

The part specific to transactional email

Marketing email and transactional email are different problems. A contact form confirmation is transactional: one recipient, expected, triggered by their own action.

Two things matter more than people expect. Send from a subdomain you use only for this, for example mail.yourdomain.pk or a dedicated sending address, so that a future marketing campaign's reputation cannot damage the deliverability of your contact form. And set the reply-to header to the person who filled in the form, not to the robot address, so replying to the notification reaches the enquirer directly.

Verify the domain with your sending provider before you write any code. Verification is DNS, DNS on .pk is slower than you expect, and there is nothing more frustrating than finishing an integration and then waiting on records. Start the DNS, then build.

The failure mode worth designing for

Your mail provider will be unavailable at some point, or the API key will be rotated and not updated, or the monthly send limit will be reached at the worst moment.

Handle it explicitly. If the send fails, log it server-side with enough detail to recover the enquiry, and show the visitor an honest error with an alternative route to reach you, which in Pakistan means a WhatsApp number. What you must never do is catch the error, show a success message, and drop the enquiry. That failure is invisible: nobody complains, nothing looks broken, and you find out months later that a channel was silently dead the whole time.

We know that specific failure well enough to be emphatic about it. Our own contact form did it, in a different way, for longer than we would like to admit.

A quick check on any domain

dig +short TXT yourdomain.pk | grep spf
dig +short TXT _dmarc.yourdomain.pk

Two commands, ten seconds. If the first returns nothing, every email your domain sends is arriving unauthenticated. If the second returns nothing, you have no policy and no reports, and you will not find out about a problem until a client mentions it.

Talk to us

If your business email or your form notifications are landing in spam, the cause is almost always one of these three records. Send us the domain and we will tell you which one is missing.