- How do I install simonschaufi/laravel-dkim in a Laravel application?
- Install it with Composer using composer require simonschaufi/laravel-dkim. Laravel's package auto-discovery registers the service provider, then you publish the config file with php artisan vendor:publish and fill in your domain, selector, and private key path. Realistic effort is a few hours, and most of that time goes to DNS and key handling rather than code.
- Which Laravel versions does laravel-dkim support, including Laravel 13?
- Version 3.6.0 is a compatibility-only release that adds Laravel 13.x support through two PRs, with no new features, no deprecations, and no documented breaking changes. The minor bump from 3.5.0 to 3.6.0 is consistent with semver for added platform support. Check composer.json to confirm whether the supported version matrix was widened or narrowed, and verify support for the Laravel version you run today rather than assuming it from the changelog. Also confirm your locked Symfony Mailer version falls inside the package's dependency range, since the signing work is delegated to Symfony's DKIM signer.
- Where should I store the DKIM private key, and how is it configured?
- The package is config-driven: the published config file holds your signing domain, selector, and the path or environment value for the private key. Keep the key out of version control and inject it through environment variables or your platform's secret manager. The package does not manage secrets for you, so who owns the key and where it is stored is a decision your team needs to make up front.
- Do I need to add a DNS TXT record for DKIM, and how long does propagation take?
- Yes. You must publish a TXT record at selector._domainkey.yourdomain containing the public key that matches the private key the package signs with. DNS propagation can take time, so plan for a wait before signatures validate end to end. The package handles signing only and does not create or manage DNS records.
- Does laravel-dkim work with SES, Postmark, SMTP relays, queues, and Mailable classes?
- It hooks into Laravel's mail-sending event pipeline, so signing happens in-process at message dispatch, before your transport takes over. That means it works with any mailer your app already uses, including SES, Postmark, and plain SMTP, and it does not interfere with queues, notifications, or Mailable classes. Your existing mail code is untouched; you just add the package and its config.
- Can I use different DKIM domains or selectors per tenant at runtime?
- The package is a single global config: one domain, one selector, one private key. If you send from multiple domains or per-tenant domains, you need runtime switching of selector and signing domain, and that is not something this package provides out of the box. Evaluate whether that limitation fits your architecture before adopting it.
- What happens if the DKIM private key path is wrong or the key is invalid?
- The private key is read from disk or from an environment value at send time, so a misconfigured path or unreadable key can fail at the moment mail is dispatched. That potentially affects all outbound messages, not just one. Treat key configuration as part of your deployment validation and send a test message after any config or infrastructure change.
- How should I rotate DKIM keys without breaking email delivery?
- Use overlapping selectors: publish the new public key at a new selector, wait for DNS to settle, switch the package config to the new selector and key, and only then retire the old record. The package does not automate any of this, so write the rotation runbook yourself. Designing that process early avoids a scramble later.
- My provider already DKIM-signs my mail, so should I use this package, and how do I verify signing works?
- Transport-layer signing such as SES Easy DKIM or MTA signing and app-layer signing are separate choices, and your team should consciously pick one or both. If you use both, make sure the signatures align with the From: domain for DMARC and watch for double-signing with mismatched selectors, which is a common misconfiguration. To verify, send a test message and inspect the Authentication-Results headers or run it through a DKIM checker, since upstream signing changes tend to surface as silent verification failures rather than exceptions.
- Is simonschaufi/laravel-dkim actively maintained, and what are the alternatives?
- It is a small, well-bounded, single-maintainer package, so the structural risk is maintenance concentration in the path of your outbound email rather than code quality. Bus factor and how quickly new Laravel majors are supported matter more than the code itself, so check the maintainer's release cadence and whether a fork or vendor patch is a credible fallback. The main alternatives are transport-level DKIM signing from your mail provider or signing directly with Symfony Mailer's DKIM signer without this wrapper.