SPF, DKIM, and DMARC together — why the missing DMARC record was blocking registration emails

Background

Registration confirmation emails were not reliably reaching users on Gmail and Outlook outside Japan — sometimes landing in spam, sometimes not arriving at all. Investigation pointed to a single root cause: the wpmm.jp domain had SPF and DKIM configured, but no DMARC record.

What each of the three does

SPF (Sender Policy Framework) declares in DNS which IP addresses are authorized to send mail for a domain. Receiving servers check the sending IP against the SPF record to confirm the source is legitimate.

DKIM (DomainKeys Identified Mail) adds a cryptographic signature to the message headers and body. The receiving server looks up the public key in DNS and verifies that the message has not been tampered with and was signed by a party controlling that domain.

DMARC (Domain-based Message Authentication, Reporting and Conformance) sits above both. It tells receiving servers what to do when SPF and DKIM alignment fails, and it collects aggregate reports about how mail from the domain is being treated.

The key point is that SPF and DKIM are independent checks. Without DMARC, there is no single authoritative statement about how the alignment result should influence delivery decisions. Major providers including Gmail weigh the absence of DMARC when scoring incoming mail.

Adding the DMARC record

The following TXT record was added to the wpmm.jp DNS:

_dmarc.wpmm.jp  TXT  "v=DMARC1; p=none; rua=mailto:info@wpmm.jp"

p=none means “collect data, but do not reject or quarantine mail that fails alignment.” Starting with p=reject or p=quarantine risks blocking legitimate mail if DKIM alignment turns out to be misconfigured somewhere. The safe approach is to start with p=none, monitor the reports, and tighten the policy gradually.

rua=mailto:info@wpmm.jp sets the destination for aggregate reports. Google and other receivers periodically send XML summaries showing which mail passed or failed SPF/DKIM alignment. This moves visibility from passive (you notice when users complain) to active (you see the numbers).

Propagation was confirmed against both Xserver’s authoritative DNS and Google Public DNS before considering the change live.

Hardening `register_free.php`

The same release also tightened the sending code itself.

Stop silently swallowing send failures: mb_send_mail() returns false on failure, but the return value was not being checked. A failed send would report success to the user and leave no trace in the server log.

// Before: return value ignored
mb_send_mail($to, $subject, $body, $headers);
echo json_encode(['status' => 'ok']);

// After: detect failure and return an error
if (!mb_send_mail($to, $subject, $body, $headers)) {
    http_response_code(500);
    echo json_encode(['status' => 'error', 'message' => 'Failed to send email']);
    exit;
}

Add headers that reduce spam scores: Reply-To, Date, and Message-ID were added explicitly.

$headers .= "Reply-To: info@wpmm.jp\r\n";
$headers .= "Date: " . date('r') . "\r\n";
$headers .= "Message-ID: <" . uniqid('wpmm-', true) . "@wpmm.jp>\r\n";

A missing Message-ID is a common spam signal. Date is required by RFC 5322 but mb_send_mail() does not always add it automatically.

What changed

After adding the DMARC record, Google started sending aggregate reports to info@wpmm.jp. The reports confirm that legitimate mail from wpmm.jp is passing DKIM alignment, and spoofed mail is failing.

Email deliverability does not improve overnight — sender reputation builds gradually. What DMARC provides immediately is the ability to see what is happening, rather than relying on user complaints to find out.