Confirm that Porkbun sends the message
A domain registered at Porkbun is not necessarily using Porkbun email hosting. First identify whether the message originates in a hosted mailbox, a forwarding rule, a third-party mailbox or a website. This guide covers Porkbun hosted email. Keep a separate route inventory for website forms and CRM mail even if they share the same visible From domain.
Record the domain, sending mailbox, authoritative nameservers, current SPF and DMARC records, and the DNS administrator. Preserve the existing zone before changes. A registrar's DNS editor may contain records that public receivers never see when another provider's nameservers are authoritative. Moving nameservers is not a prerequisite for authentication and should not be bundled into this change.
Select the appropriate DNS workflow
For Porkbun hosted email, the Domain Management envelope icon opens Email Hosting and Forwarding. Under Additional Notices & Configuration, the Configure DMARC control also configures DKIM. The provider says this control appears only with an email-hosting service. Review the intended change and existing policy before accepting an automatic configuration. Porkbun DKIM and DMARC.
If the panel reports a DMARC Warning, external nameservers may prevent automatic publishing. That is not evidence that the mailbox is unsupported. Obtain the generated records and arrange publication with the authoritative DNS administrator. Check the resulting public answers before relying on the account status.
For external DNS, Porkbun documents its SPF include as _spf.porkbun.com. Its instructions also explain how to copy the account's default._domainkey and _dmarc TXT records from the DNS Records panel. Copy the public key exactly. Merge applicable sender permissions into one SPF record instead of publishing a second one. Porkbun external-DNS instructions.
Preserve existing mail while publishing
Do not use the external-DNS article's full mailbox-migration recipe as an instruction to replace working MX records during an authentication-only change. MX migration changes inbound delivery and needs its own approved plan. Likewise, inspect any existing DMARC policy before copying a generated replacement: other senders and reporting destinations can depend on it.
For the DKIM record, distinguish the host field from the TXT value. If the editor appends example.com, entering a complete hostname into a relative-name field can create default._domainkey.example.com.example.com. Confirm the actual public lookup location, not just the displayed row. SPF is published as TXT at the relevant envelope domain. Its evaluated policy must remain within the protocol's DNS-lookup limits. SPF rules.
Test mailbox sending and forwarding separately
Send a harmless message from the hosted mailbox using its normal sending client to a controlled external recipient. Save the complete original and receiver-added Authentication-Results. Then test any forwarding workflow separately; do not substitute forwarded mail for the direct-send baseline.
- Test: Hosted mailbox direct send; Capture: From, Return-Path, all DKIM d= and s= values; Pass condition: At least one passing method aligns under the actual policy
- Test: Third-party website form; Capture: Sender configuration and received original; Pass condition: Evaluate that separate sending service, not registrar ownership
- Test: Forwarded message; Capture: Original signature and post-forward results; Pass condition: Diagnose changes independently of the direct mailbox path
- is table is a test plan, not a report of executed messages. For a synthetic From of user@example.com and a validated DKIM d=example.com, the signing domain is an exact match. A passing signature for an unrelated provider domain does not establish that alignment. Reply-To is useful for reply routing but is not the domain DMARC aligns. DMARC.
Resolve the specific failure
If the automatic control is absent, confirm the product entitlement instead of hunting for an unrelated registrar setting. If the panel says configured but DNS lacks the key, compare the authoritative nameservers and zone. If the key exists but the message is unsigned, verify the SMTP route and mailbox, then give support a redacted message ID and observed signing state. Do not publish a private key or mailbox password in a ticket.
If SPF stops working after a merge, restore the prior known-good record and review each include before retrying. If another sender breaks after an automatic DMARC change, restore the approved previous policy rather than leaving an accidental replacement active. Monitor the exact mailbox and affected applications through the next normal sending cycle. Keep DNS snapshots and originals with the change record, and review obsolete permissions after a mailbox migration. No live mailbox, DNS edit or delivered message was tested for this documentary guide.
Reconcile the product scope before acting
For written case PB-01, assume Porkbun hosts the mailbox but example.com delegates DNS elsewhere and also uses a CRM. The Configure DMARC status is not evidence that the external zone changed. Obtain the actual generated key and proposed policy, preserve the CRM’s legitimate permissions and publish only through the authorized zone owner. If the CRM’s sending identity is unknown, do not guess an include or replace the existing SPF policy wholesale. Keep each required DNS and message observation pending until actually collected. No configuration or mail send occurred here.
Preserve the enforcement boundary
RFC 9989 Section 7.4 requires valid DKIM, not SPF alone, for domains publishing p=reject, and warns about indirect-mail and mailing-list interoperability. A single successful direct-message test is not proof that every legitimate route is ready for stronger policy. Keep existing approved protection while diagnosing the actual gap; any policy change needs its own decision.