The Email Infrastructure Engineer Interview

An email infrastructure engineer interview is one of the few engineering interviews where being approximately right is being wrong. Mail systems run on precise specifications, and a panel of deliverability engineers will catch the moment you confuse the envelope sender with the From header, or claim SPF authenticates the visible sender. This guide is for the email deliverability engineer interview, the mail systems engineer interview, and any MTA-focused role, and it goes deep on the authentication specifics because that is where candidates are made or broken.

The work sits at the intersection of SMTP, DNS, cryptography, and reputation. The interview tests whether you understand how a message is authenticated, why it lands in the inbox or the spam folder, and how you keep a sending platform trusted.

What an MTA actually does

Expect to explain the mail transfer agent from the ground up. A message moves from a Mail User Agent to a Mail Submission Agent on port 587, then between MTAs over SMTP on port 25, and finally to a Mail Delivery Agent. Know Postfix at least conceptually, and ideally one modern MTA such as Postal or Haraka.

Core areas:

• The Postfix component model: smtpd for inbound, smtp/qmgr for outbound and queueing, and how master.cf and main.cf differ.
• The queue lifecycle: incoming, active, deferred, and the hold queue. Be ready to explain why a message sits in deferred (a soft 4xx failure or a temporary destination problem) and how retry backoff works.
• SMTP response codes. A 250 is acceptance, a 4xx is a temporary failure the sender should retry, and a 5xx is a permanent rejection. Knowing the difference is the difference between a bounce and a deferral.

SPF, DKIM, DMARC, and the alignment trap

This is the heart of the interview. The three standards are separate RFCs that do different jobs, and the most common candidate mistake is treating them as interchangeable.

SPF, defined in RFC 7208, validates the envelope sender. It publishes a DNS TXT record listing the IP addresses authorized to send for a domain, and the receiver checks the connecting IP against the domain in the SMTP MAIL FROM command, also called the envelope sender or Return-Path. Note carefully: SPF checks the envelope sender, not the From header the user sees. That distinction is the trap.

DKIM, defined in RFC 6376, validates a domain identity cryptographically. The sender signs selected headers and the body with a private key and adds a DKIM-Signature header. The receiver fetches the public key from DNS at the selector and the signing domain (the d= tag) and verifies the signature. A valid DKIM signature proves the message was authorized by the d= domain and was not altered in transit.

DMARC, defined in RFC 7489, ties the two together and adds the piece neither has alone: alignment. DMARC does not merely ask whether SPF or DKIM passed. It requires that at least one of them passes and that the passing domain aligns with the domain in the visible From header. This is what stops an attacker from passing SPF on their own domain while spoofing your From address.

Be precise about alignment modes, because interviewers probe here:

• SPF alignment compares the Return-Path domain to the From header domain.
• DKIM alignment compares the d= signing domain to the From header domain.
• Relaxed alignment (the default) passes when the two share the same organizational domain, so mail.example.com aligns with example.com.
• Strict alignment requires an exact match.
• The DMARC record sets these with aspf and adkim tags.

A senior-level point worth raising unprompted: DKIM alignment is generally more reliable than SPF alignment because it survives forwarding. When a message is forwarded, the connecting IP changes and SPF breaks, but the DKIM signature travels with the message and still verifies. This is why mature platforms lean on DKIM as the durable authentication path.

You should also be able to explain why a DMARC p=reject policy can break legitimate mailing-list traffic (lists modify the body and subject, breaking DKIM and changing the envelope sender), and how ARC lets trusted intermediaries vouch for authentication results across a hop.

Reputation: IP and domain

Authentication gets you the right to be evaluated; reputation decides whether you reach the inbox. Be ready to discuss both, because they are scored separately by the major mailbox providers.

• IP reputation is tied to the sending IP and built through consistent volume and low complaint rates. Warming a new IP means ramping volume gradually so a provider learns to trust it rather than seeing a sudden spike and throttling you.
• Domain reputation follows the sending domain and the authenticated d= domain, and it persists even if you change IPs. It is harder to repair than IP reputation.
• Engagement signals matter. Opens, replies, and the absence of spam complaints feed reputation. Sending to unengaged or stale addresses degrades it.
• Bounce handling is operational hygiene. A hard bounce (a 5xx, address does not exist) must suppress the address immediately. Continuing to send to addresses that hard-bounce is one of the fastest ways to wreck a domain's standing.

Since early 2024, Google and Yahoo require bulk senders to authenticate with SPF and DKIM, publish a DMARC policy, keep spam complaint rates low, and support one-click unsubscribe. Knowing that requirement and why it exists is table stakes.

Queues, blocklists, and feedback loops

Operational rounds test how you run a platform under load and under trouble.

• Queue management: how deferred mail retries, how to read a stuck queue, and how to keep a backlog from cascading when a major destination throttles you.
• Blocklists (DNSBLs such as Spamhaus). Know how a listing happens, how to check one, and the delisting process. A candidate who has actually requested delisting and fixed the root cause stands out.
• Feedback loops: subscribing to provider complaint feeds so a recipient marking a message as spam suppresses that address automatically.
• Dedicated versus shared IPs, and when each makes sense given volume and the risk of a noisy neighbor on a shared pool.
• TLS for transport (opportunistic STARTTLS) and the role of MTA-STS and TLS-RPT in enforcing and reporting on encrypted delivery.

Putting it together in a scenario

A common closing prompt: messages from a new domain are landing in spam at one major provider. Walk it methodically. Confirm SPF, DKIM, and DMARC all pass and align (read the Authentication-Results header). Check whether the domain and IP are warmed, then complaint rates, blocklist status, content, and list hygiene. The structure of your answer, isolating authentication from reputation from content, is what signals real experience.

Because this material is dense with precise terms that are easy to fumble under pressure, practice saying the SPF-versus-DKIM distinction and the alignment explanation out loud until they are clean. Speaking it is how you find the spots where you only half-know the spec, which is the exact thing a panel will press on and the exact thing Mythic Intel grades for accuracy.